public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Milian Wolff <mail@milianw.de>
Cc: elfutils-devel@sourceware.org
Subject: Re: dwfl_module_addrinfo and @plt entries
Date: Fri, 07 Jul 2017 11:03:00 -0000	[thread overview]
Message-ID: <1499425412.14595.78.camel@klomp.org> (raw)
In-Reply-To: <3866408.Fn4hcxxxTc@milian-kdab2>

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).

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? 

Thanks,

Mark

  reply	other threads:[~2017-07-07 11:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-04  0:41 Milian Wolff
2017-01-04 13:42 ` Mark Wielaard
2017-01-06 10:28   ` Milian Wolff
2017-01-06 19:17     ` Mark Wielaard
2017-07-05 13:34       ` Milian Wolff
2017-07-07 11:03         ` Mark Wielaard [this message]
2017-07-10 11:06           ` Milian Wolff
2017-08-28 14:28             ` Milian Wolff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1499425412.14595.78.camel@klomp.org \
    --to=mark@klomp.org \
    --cc=elfutils-devel@sourceware.org \
    --cc=mail@milianw.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).