I've attached a patch for a first stab at a BPatch_object. The interface is pretty spartan at the moment, but if I recalled correctly it will give you everything you need to have.
As with BPatch_modules, a BPatch_object is accessed from the BPatch_image. Instead of putting in a by-name or by-address lookup, you just get the full list (for now).
Objects support converting an offset to an address, creating points, and looking up functions.
Let me know if there is any additional functionality you need. This is against current git master; it should apply cleanly to anything remotely recent, however.
Drew
Attachment:
BPatch_object.patch
Description: Binary data
On Apr 30, 2012, at 6:00 PM, Josh Stone wrote:
> On 04/30/2012 03:27 PM, Andrew Bernat wrote:
>> The reason I bring it up is because it has bitten us in the posterior
>> many times. Once we build a "return one" interface, it's _really_
>> hard to generalize it.
>
> Ok, makes sense.
>
>> We can turn a file, offset pair into an address with complete
>> accuracy; this is making some assumptions about how static libraries
>> work, but I think they can be worked out. For non-static-libraries,
>> the offset has to tell us where in the file we are (text, some other
>> code, data, etc.) and we can use that to distinguish which load
>> address we want.
>
> What do you mean by "the offset has to tell us where ..."? Just that
> the offset provided has to make sense for one of those locations? Or
> must the caller specify some context along with the offset?
>
> If you need some context, like which PT_LOAD segment, that might be hard
> for me to know. Whatever's executable at that offset, I suppose. :)
>
>> BTW, SymtabAPI is working on disk, and so has no concept of a "loaded
>> at" address. There is a wrapper provided for that, but that is a
>> logical thing to expose through BPatch.
>
> Great.
>
>
> Josh
--
Andrew Bernat
Paradyn Project
bernat@xxxxxxxxxxx
http://www.cs.wisc.edu/~bernat
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}