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@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
_______________________________________________
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api