From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69705 invoked by alias); 10 Jul 2017 11:06:38 -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 69685 invoked by uid 89); 10 Jul 2017 11:06:37 -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.3 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=juli, beside, U*mail, theoretically X-Spam-Status: No, score=-6.3 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, 10 Jul 2017 11:06:35 +0000 Received: from agathebauer.localnet (ip5f5bd540.dynamic.kabel-deutschland.de [95.91.213.64]) by dd17628.kasserver.com (Postfix) with ESMTPSA id 7BE0962813E4; Mon, 10 Jul 2017 13:06:32 +0200 (CEST) From: Milian Wolff To: Mark Wielaard Cc: elfutils-devel@sourceware.org Subject: Re: dwfl_module_addrinfo and @plt entries Date: Mon, 10 Jul 2017 11:06:00 -0000 Message-ID: <1615178.UZrlLCQOm2@agathebauer> In-Reply-To: <1499425412.14595.78.camel@klomp.org> References: <4389913.7LHyNoxDn3@agathebauer> <3866408.Fn4hcxxxTc@milian-kdab2> <1499425412.14595.78.camel@klomp.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1889649.NOCHGm8lzr"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-IsSubscribed: yes X-SW-Source: 2017-q3/txt/msg00002.txt.bz2 --nextPart1889649.NOCHGm8lzr Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Content-length: 2793 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. Thanks -- Milian Wolff mail@milianw.de http://milianw.de --nextPart1889649.NOCHGm8lzr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit Content-length: 195 -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQQ9hWiGkJfGXJj40nYMDrISzR0TkwUCWWNfswAKCRAMDrISzR0T k25DAJ0fv2QU2xuLjK0AXhwT0nKcV/ehXACgrPBwInX4A+nQ5yON+gMe3Vzc9wY= =wGrF -----END PGP SIGNATURE----- --nextPart1889649.NOCHGm8lzr--