This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: dwfl_module_addrinfo and @plt entries
- From: Milian Wolff <mail at milianw dot de>
- To: elfutils-devel at sourceware dot org
- Cc: Mark Wielaard <mark at klomp dot org>
- Date: Mon, 28 Aug 2017 15:25:29 +0200
- Subject: Re: dwfl_module_addrinfo and @plt entries
- Authentication-results: sourceware.org; auth=none
- References: <4389913.7LHyNoxDn3@agathebauer> <1499425412.14595.78.camel@klomp.org> <1615178.UZrlLCQOm2@agathebauer>
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