Re: [DynInst_API:] BPatch_object

[Andrew Bernat <bernat@xxxxxxxxxxx>]

I'm resending this so that it's included in the dyninst-api list archives; since I wasn't a member before my response was bounced. 

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. 

... 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. 

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. 

Drew

--

Andrew Bernat

Paradyn Project

bernat@xxxxxxxxxxx

http://www.cs.wisc.edu/~bernat

--

Andrew Bernat

Paradyn Project

bernat@xxxxxxxxxxx

http://www.cs.wisc.edu/~bernat