Makes sense to me.
Jeff
On 4/30/2012 4:26 PM, Andrew Bernat wrote:
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
bernat@xxxxxxxxxxx <mailto:bernat@xxxxxxxxxxx>
http://www.cs.wisc.edu/~bernat
--
Andrew Bernat
Paradyn Project
bernat@xxxxxxxxxxx <mailto:bernat@xxxxxxxxxxx>
http://www.cs.wisc.edu/~bernat
_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx <mailto:Dyninst-api@xxxxxxxxxxx>
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
--
Andrew Bernat
Paradyn Project
bernat@xxxxxxxxxxx <mailto:bernat@xxxxxxxxxxx>
http://www.cs.wisc.edu/~bernat
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}