On Wednesday, January 4, 2017 2:42:23 PM CET Mark Wielaard wrote: > On Wed, Jan 04, 2017 at 01:41:26AM +0100, Milian Wolff wrote: > > how do I get symbol information for @plt entries? > > Short answer. You cannot with the dwfl_module_getsym/addr* > functions. And we don't have accessors for "fake" symbols > (yet). Sorry.
Thanks for the clarification Mark. > Longer answer. An address pointing into the PLT does > really point to an ELF symbol. You mean: does _not_ Right? > The PLT/GOT contains entries > that are architecture specific "jump targets" that contain > (self-modifying) code/data on first access. A PLT entry > is code that sets up the correct (absolute) address of > a function on first access. And on second access it fetches > that function address and jumps to it. Since this is > architecture specific we would need a backend function > that translates an address pointing into the PLT into > an actual function address. You would then be able to > fetch the actual ELF symbol that address is associated > with. > > If we have such a backend function then we could even > do what BFD apparently does. Which is to then create a > "fake" symbol with as name real_function@plt. But I am > not sure such fake symbols are very useful (and will > quickly become confusing since they aren't real ELF > symbols). So the objdump command I used is leveraging BFD internally to give me the @plt names? I noticed that I also see @plt in perf, which is also probably using BFD internally. That at least clarifies why it works in some tools but not in when using dwfl. > Hope that helps. And maybe inspires someone (you?) to > write up such a backend function and corresponding > dwfl frontend function. It does help, thanks. I'm interested in contributing such functionality, but, sadly, I'm not sure when I'll get the time to actually do it. Cheers -- Milian Wolff m...@milianw.de http://milianw.de
