Re: [DynInst_API:] BPatch_object

[Josh Stone <jistone@xxxxxxxxxx>]

On 04/27/2012 09:18 AM, Andrew Bernat wrote:
> On Apr 27, 2012, at 9:58 AM, Jeff Hollingsworth wrote:
> 
>> I (perhaps as the creator) do like BPatch_module.  It really should
>> be a compilation unit (which I think people find natural).  At some
>> point we got in the habbit of making it the whole program when we
>> lacked enough debug info to find it.  Perhaps the right thing is to
>> retain Module for compile units, but if we can't find a compile
>> unit then modules are not defined. In that case either Object (if I
>> understand the object proposal correctly) or BPatch_Image would be
>> the path the the contained bits.
> 
> I think there is value in both a compilation unit (BPatch_module) and
> whole file (BPatch_object). The compilation unit provides a useful
> container for functions, variables, and other information; in some
> cases it's necessary (static functions, static libraries, and the
> like). The whole file allows someone to do an address- or
> filename-based lookup that cannot be done at the module level.

I definitely see the value in having a view of compilation units.  I
think my initial confusion was that I expected "module" to mean the file
level, as I'm now proposing with object.  And the inconsistency when it
came to libraries was a little jarring.

> ... so I think we should just add BPatch_object as a container of
> BPatch_modules. It enlarges the interface, but also provides symmetry
> with SymtabAPI, ParseAPI, and PatchAPI.

All the better.

> The one change I would make to modules is to revisit the "shared
> libraries are a single module" decision. While this makes sense for
> things like libc, it doesn't necessarily make sense for user
> libraries that are linked in. I don't have strong feelings about
> that, though.

With the proper debuginfo, libraries can be broken into compilation
units too, so they shouldn't really be called a monolithic module.  Many
programs also organize all their interesting work into libraries, e.g.
libxul, libpython, so treating those differently than the core
executable is limiting.

So I agree with what I think Jeff was saying.  Represent all mapped
files as BPatch_object, and when info about compilation units are
available, break it down into BPatch_module too.  And there's no need to
invent a module when CUs aren't present.


Josh