Re: [DynInst_API:] BPatch_object

[Josh Stone <jistone@xxxxxxxxxx>]

On 04/30/2012 02:23 PM, Andrew Bernat wrote:
> On Apr 30, 2012, at 4:15 PM, Josh Stone wrote:
> 
>> Hmm.  It seems like in practice (at least for Linux/ELF), there's 
>> usually only one code region, but I suppose that's not necessary
>> by specification.
> 
> The normal is .text. However, if we ever want to represent rewritten
> binaries, we'll need more than that.

There's .text, .init, .fini, etc, but usually these are bottled up in a
single segment, as shown in program headers (readelf -l).  But there
could be many segments, as I guess your rewriting shows.

>> So I think for multiple address regions to be useful, we'll also
>> need to know how that relates to the file in question.  Perhaps
>> simplest is to turn it into a (start, end, file_offset) tuple.
> 
> That information can be gathered with SymtabAPI, and I want to
> duplicate as little as possible.
> 
> In fact, SymtabAPI will give code region information. Is there any
> reason for BPatch_object to not just support function lookup by
> address, and elide the whole problem of address bounds?

Because in general, I have basically a file+offset pair, and I need to
turn that into an address in order to do any sort of instrumentation
point lookup.  Even a function lookup seems not directly interesting, as
I'm not trying to specify things at the function level.

I see functions in SymtabAPI to map offsets to the functions, variables,
modules, etc., but I don't see one to compute the plain address.

Perhaps that can be a BPatch_object method, like ->offsetToAddr() ?
Then I can feed that to createPointsAtAddr().

Josh