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

[Josh Stone <jistone@xxxxxxxxxx>]

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.