So are folks in agreement?
We will create a hierarchy as follows:
BPatch_image contains BPatch_objects, which in turn contain BPatch_modules. ... we leave the old interface intact for backwards compatibility
BPatch_object copies those BPatch_module methods that make sense, while adding the following:
Full name (with path) and file name; I would suggest "pathName" and "name" as methods. Address bounds. Since there is no reason to have a single contiguous code region, I would suggest returning a vector of (start, end) pairs.
Finally, add a "find BPatch_object by address" method to BPatch_image.
Drew
On Apr 27, 2012, at 2:24 PM, Andrew Bernat wrote: 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
-- 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}