Re: [DynInst_API:] RFC: updating module definitions in Dyninst and Symtab

[Bill Williams <bill@xxxxxxxxxxx>]

On 09/17/2015 02:27 PM, Josh Stone wrote:
> On 09/17/2015 11:58 AM, Bill Williams wrote:
> > For historical reasons, modules at the BPatch and Symtab levels have
> > meant different things when applied to an executable (constituent .o
> > files) and a shared library (one module for the library itself). There's
> > no longer any good reason for this outside of backwards compatibility,
> > and we'd like to make this consistent: for everything where we know the
> > .o file associated with a chunk of the binary, there should be a
> > corresponding module. Anything that isn't in a known, named module goes
> > into DEFAULT_MODULE for that binary, as it does presently (or into a
> > module bearing the binary's filename; input on which way to make things
> > consistent is welcome here).
> >
> > If this is a change that will break any of your tools, please let us
> > know ASAP. Thanks.
> For systemtap, we only want to deal with an entire ELF binary, not
> individual compilation units (modules).  This is why I requested
> BPatch_object to be added.
>
> I think it sounds fine to break up shared libraries into BPatch_modules
> for their true CUs, except registerDynLibraryCallback uses modules.
> That works fine now when they're only one module -- I just call
> getObject and I'm done.  I don't really want to get a flood of module
> callbacks for the same object though.
>
> Maybe the library callback should be changed to report BPatch_object?
> Then one can use o->modules() to break it down if needed.
Good catch there; the library callback should change to report 
BPatch_objects as that's the best semantic match regardless.
--bw