Re: dwfl_module_addrinfo and @plt entries

[Milian Wolff <mail@milianw.de>]

On Monday, July 10, 2017 1:06:27 PM CEST Milian Wolff wrote:
> On Freitag, 7. Juli 2017 13:03:32 CEST Mark Wielaard wrote:
> > Hi Milian,
> > 
> > First congrats on https://www.kdab.com/hotspot-gui-linux-perf-profiler/
> > Very cool.
> > 
> > On Wed, 2017-07-05 at 15:34 +0200, Milian Wolff wrote:
> > > On Friday, January 6, 2017 8:17:53 PM CEST Mark Wielaard wrote:
> > > I have now looked into this issue again and have found a way to
> > > workaround
> > > this limitation outside of elfutils, by manually resolving the address
> > > in
> > > a
> > > .plt section to a symbol. See:
> > > 
> > > https://github.com/KDAB/perfparser/commit/
> > > 885f88f3d66904cd94af65f802232f6c6dc339f4
> > > 
> > > This seems to work in my limited tests (only on X86_64). Beside the
> > > 32bit/
> > > 64bit difference, it isn't really platform dependent, is it? Or was this
> > > what you had in mind when you said the elfutils code would be
> > > "architecture specific [and] we would need a backend function that
> > > translates an address pointing into the PLT into an actual function
> > > address"?
> > > 
> > > If my code is roughly OK, then I'll try to put it into a patch for
> > > elfutils
> > > and submit it there. If it's fundamentally broken, please tell me. I
> > > still
> > > plan to get this functionality upstream into elfutils.
> > 
> > Thanks for the research. I don't know if the PLT/GOT resolving works
> > identical for all architectures. But yes, it does look like what you
> > came up with is in general architecture independent.
> > 
> > In general it would be nice if we could avoid any name based section
> > lookups (or only do them as fallbacks) since we might not have section
> > headers (for example if you got the ELF image from memory).
> 
> Yes, the name comparison is ugly but I don't know any alternative. The
> sh_type is just SHT_PROGBITS afair and I couldn't find anything else to
> use. From what I gathered online, one could even (theoretically) change the
> name of the section and it would still work fine but my mapping would
> break. That said, at least this works for the common case.
> 
> > I wonder if we can get all the information needed from the dynamic
> > segment. For example it seems we have a DT_JMPREL that points directly
> > at the .plt table, DT_PLTREL gives you what kind of relocation entries
> > REL or RELA it contains and DT_PLTRELSZ gives the size of the plt
> > table.
> > 
> > In your code you get the GOT address through DT_PLTGOT, but then use
> > that address to lookup the .got.plt section and use its sh_addr to index
> > into the table. Why is that? Isn't that address equal to what you
> > already got through DT_PLTGOT?
> 
> Indeed, that is convoluted. I tried to reverse-engineer the code from elf-
> dissector, which does this mapping in reverse (no pun intended). Maybe I
> over- complicated it. I'll research this when I'm back from vacation in two
> weeks.

Hey Mark,

more than two weeks passed, but I finally had some time to investigate the 
above. I have a hard time justifying what I wrote, I can only explain what I'm 
seeing. Can you maybe add your comments in the below? I think I'm just missing 
something that you have in your mind to shortcut my code:

- find dynamic segment via SHT_DYNAMIC (1st loop)
- in there, find address of PLTGOT segment via DT_PLTGOT
- find corresponding segment (2nd loop) for PLTGOT
- in there, find address for requested symbol index, offset by two
- ...

I mean, searching the address in the first loop is not a goal per se. What I'm 
looking for is the Scn/Shdr that contains the PLTGOT. The first loop allows me 
to identify the PLTGOT via it's address, but to actually get my hands on the 
corresponding Scn/Shdr I still need the second loop, no? Or can I somehow 
translate the PLTGOT address to a Scn/Shdr directly?

Thanks

-- 
Milian Wolff
mail@milianw.de
http://milianw.de