On May 7, 2012, at 6:42 PM, Josh Stone wrote:
It looks like you already pushed this to master, so I just tested on
that code directly.
Yup.
This is fine. I think we'll also want a callback for dlopen/dlclose
type of events, so one can see objects that come and go.
Right now there's a callback that hands you a BPatch_module; I need to add some sort of "get object from module" upcall.
I think this is not quite correct. I'm seeing that imageOffset() and
dataOffset() are returning large numbers, apparently the actual load
addresses. This may be because most of my system libraries are already
prelinked. But if the offset parameter is meant to be a *file* offset,
then this range check doesn't make sense.
Ah. This will require some thought to see what should be done at the Symtab level. The offset calls are reporting load addresses, yes, which will be large for an a.out or a address-optimized library.
The ET_EXEC thing also reminds me why I created isSharedLib() before.
It's pretty common with these to deal in absolute addresses, rather than
file+offset, so I was using isSharedLib to decide whether relocation was
needed. In this new world, it would similarly help me decide whether an
offsetToAddr call is needed.
That's me being a little bit lazy, though -- I could also make sure to
always generate file-relative addresses, so it's always expected to be
converted. In fact, I'll go ahead and do that in my client code. It
still may be an interesting property for BPatch_object, is it EXEC/DYN.
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}