From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14232 invoked by alias); 5 Jul 2017 13:34:30 -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 14194 invoked by uid 89); 5 Jul 2017 13:34:29 -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=-1.6 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=Wolff, wolff, beside, fundamentally X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no 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; Wed, 05 Jul 2017 13:34:27 +0000 Received: from milian-kdab2.localnet (unknown [185.28.184.2]) by dd17628.kasserver.com (Postfix) with ESMTPSA id 16C036280948; Wed, 5 Jul 2017 15:34:25 +0200 (CEST) From: Milian Wolff To: elfutils-devel@sourceware.org Cc: Mark Wielaard Subject: Re: dwfl_module_addrinfo and @plt entries Date: Wed, 05 Jul 2017 13:34:00 -0000 Message-ID: <3866408.Fn4hcxxxTc@milian-kdab2> In-Reply-To: <20170106191753.GB8669@stream> References: <4389913.7LHyNoxDn3@agathebauer> <4367790.cbajsgPFcv@milian-kdab2> <20170106191753.GB8669@stream> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2017-q3/txt/msg00000.txt.bz2 On Friday, January 6, 2017 8:17:53 PM CEST Mark Wielaard wrote: > On Fri, Jan 06, 2017 at 11:28:25AM +0100, Milian Wolff wrote: > > On Wednesday, January 4, 2017 2:42:23 PM CET Mark Wielaard wrote: > > > Longer answer. An address pointing into the PLT does > > > really point to an ELF symbol. > > > > You mean: does _not_ > > Right? > > Yes, I meant "does not point". > > > > If we have such a backend function then we could even > > > do what BFD apparently does. Which is to then create a > > > "fake" symbol with as name real_function@plt. But I am > > > not sure such fake symbols are very useful (and will > > > quickly become confusing since they aren't real ELF > > > symbols). > > > > So the objdump command I used is leveraging BFD internally to give me the > > @plt names? I noticed that I also see @plt in perf, which is also > > probably using BFD internally. That at least clarifies why it works in > > some tools but not in when using dwfl. > > binutils objdump certainly does. > > > > Hope that helps. And maybe inspires someone (you?) to > > > write up such a backend function and corresponding > > > dwfl frontend function. > > > > It does help, thanks. I'm interested in contributing such functionality, > > but, sadly, I'm not sure when I'll get the time to actually do it. > > Thanks, wish I had spare time myself :) 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. Cheers -- Milian Wolff mail@milianw.de http://milianw.de