And replying to myself again - do a pull and give "BPatch_object::fileOffsetToAddr" a try. It should do what you want.
Drew
On May 14, 2012, at 10:20 AM, Andrew Bernat wrote: On May 10, 2012, at 4:36 PM, Andrew Bernat wrote: 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.
Okay, I've got a solution for doing the lookups. Right now it will require the use of the SymtabAPI interface to convert a file offset to a "disk offset". In general, we should decide which option makes more sense and use it.
I have to fix some parsing bugs firat, but expect an update to master shortly.
Drew 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.
Let me look into the best way to do file offset lookups.
Drew
-- Andrew Bernat Paradyn Project
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
-- Andrew Bernat Paradyn Project
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
-- Andrew Bernat Paradyn Project
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}