From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31188 invoked by alias); 28 Aug 2017 14:28:21 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 30648 invoked by uid 89); 28 Aug 2017 14:28:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.1 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=january, January, H*F:U*mail, translates X-Spam-Status: No, score=-6.1 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: dd17628.kasserver.com Received: from dd17628.kasserver.com (HELO dd17628.kasserver.com) (85.13.138.83) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 28 Aug 2017 14:28:17 +0000 Received: from mail.milianw.de (unknown [185.28.184.2]) by dd17628.kasserver.com (Postfix) with ESMTPSA id E2B1B628070B; Mon, 28 Aug 2017 16:28:14 +0200 (CEST) From: Milian Wolff To: elfutils-devel@sourceware.org Cc: Mark Wielaard Subject: Re: dwfl_module_addrinfo and @plt entries Date: Mon, 28 Aug 2017 14:28:00 -0000 Message-ID: <8177317.TH60zu3zqI@milian-kdab2> In-Reply-To: <1615178.UZrlLCQOm2@agathebauer> References: <4389913.7LHyNoxDn3@agathebauer> <1499425412.14595.78.camel@klomp.org> <1615178.UZrlLCQOm2@agathebauer> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2017-q3/txt/msg00095.txt.bz2 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