From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89992 invoked by alias); 6 Jan 2017 10:28:39 -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 89897 invoked by uid 89); 6 Jan 2017 10:28:38 -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=H*F:U*mail, january, January 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 From: Milian Wolff To: Mark Wielaard Cc: elfutils-devel@sourceware.org Subject: Re: dwfl_module_addrinfo and @plt entries Date: Fri, 06 Jan 2017 10:28:00 -0000 Message-ID: <4367790.cbajsgPFcv@milian-kdab2> In-Reply-To: <20170104134223.GN2187@stream> References: <4389913.7LHyNoxDn3@agathebauer> <20170104134223.GN2187@stream> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-SW-Source: 2017-q1/txt/msg00006.txt.bz2 On Wednesday, January 4, 2017 2:42:23 PM CET Mark Wielaard wrote: > On Wed, Jan 04, 2017 at 01:41:26AM +0100, Milian Wolff wrote: > > how do I get symbol information for @plt entries? > > Short answer. You cannot with the dwfl_module_getsym/addr* > functions. And we don't have accessors for "fake" symbols > (yet). Sorry. Thanks for the clarification Mark. > Longer answer. An address pointing into the PLT does > really point to an ELF symbol. You mean: does _not_ Right? > The PLT/GOT contains entries > that are architecture specific "jump targets" that contain > (self-modifying) code/data on first access. A PLT entry > is code that sets up the correct (absolute) address of > a function on first access. And on second access it fetches > that function address and jumps to it. Since this is > architecture specific we would need a backend function > that translates an address pointing into the PLT into > an actual function address. You would then be able to > fetch the actual ELF symbol that address is associated > with. > > 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. > 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. Cheers -- Milian Wolff mail@milianw.de http://milianw.de