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 m...@milianw.de http://milianw.de
