Re: [DynInst_API:] Modules within shared libraries

["Rogers, Kelly K" <Kelly.Rogers@xxxxxxxxxxxx>]

I’ve actually tested it out and the Symtab modules behave the same way.

 

6.2 Class Module

 

This class represents the concept of a single source file. Currently, Modules are only identified for the executable file; each shared library is made up of a single Module, ignoring any source file information that may be present.

 

From: Dyninst-api [mailto:dyninst-api-bounces@xxxxxxxxxxx] On Behalf Of Bill Williams
Sent: Wednesday, September 16, 2015 11:49 AM
To: dyninst-api@xxxxxxxxxxx
Subject: Re: [DynInst_API:] Modules within shared libraries

 

On 09/15/2015 07:35 PM, Rogers, Kelly K wrote:

Hello,

 

I’ve been working with the dyninst code, and am wanting to display the module names that are contained in a shared library.  Currently, on a running process I can use getModules() to get all the modules, some being actual files, and some being shared libraries. (eg, I’ll get file1.c, file2.c, libxxx.so, but there is a module file3.c that is within my libxxx.so).  I would like to be able to get access to the module, and looking at the APIs, it seems that theoretically I should be able to use the modules() function within the BPatch_object class.  However, when I use this on libxxx.so, it just returns libxxx.so.   Is there any other way that I’m missing that I can get access to these  modules within modules? Or are all the functions of the different modules within file3.c all just combined together and put into the module libxxx.so?

 

I think we're lumping modules together in .so files for backwards compatibility reasons. Which are, in all likelihood, dumb reasons and we should make modules() work consistently at some point. What says the list? (IIRC you may also be able to get useful modules from the BPatch_image.)

In the meantime, I'm 99% certain that the SymtabAPI notion of modules is correct and consistent, and there's at least one way to go from a BPatch_* to a Symtab...that should be sufficient for data dumping.

Thanks,

Kelly

_______________________________________________

Dyninst-api mailing list

Dyninst-api@xxxxxxxxxxx

https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api