From: Roland McGrath <roland@redhat.com>
To: Mark Wielaard <mjw@redhat.com>
Cc: systemtap <systemtap@sources.redhat.com>
Subject: Re: dwfl_module_relocate_address() versus base address
Date: Tue, 16 Dec 2008 09:12:00 -0000 [thread overview]
Message-ID: <20081216091138.68D1FFC351@magilla.sf.frob.com> (raw)
In-Reply-To: Mark Wielaard's message of Monday, 15 December 2008 13:06:01 +0100 <1229342761.3457.13.camel@dijkstra.wildebeest.org>
> Aha! Doh. Yes, things make a lot more sense now. Since older/current
> versions of dwfl_module_relocate_address() will have this bug I am using
> dwfl_module_address_section() now, which does seem to do the right
> thing.
Note that for ET_REL that call also incurs a big cost you don't otherwise
need (applying relocs to the section data).
> Although I am still confused how this ever worked before.
The buggy code only affects ET_DYN(-like) with separate debuginfo, not
ET_REL. It probably wasn't noticed before because usually vmlinux is not
separate debuginfo, it's a whole unstripped copy, and .ko are ET_REL.
> Also for the kernel we still do things slightly differently (making
> things relative to _stext) .
The kernel is treated as ET_DYN by libdwfl (hence the -like). Though the
file says ET_EXEC, it really behaves like ET_DYN on CONFIG_RELOCATABLE=y
kernels. This is just FYI, I guess.
> This is not completely true. I was confused since we also rely on the
> secname produced by dwfl_module_relocation_info() (being empty for
> ET_DYN). So that is now also replicated by hand in the new patch. It is
> getting slightly messy now :{
Since this code does getelf anyway (which, incidentally, imposes all the
costs of dwfl_module_address_section on every section), you can just do a
different workaround. You can even skip the bad overhead, because you
don't need to do any workaround for ET_REL files anyway:
if (ki == 0 && secname != NULL && secname[0] == '\0')
{
check for bug
}
So, you can do getelf + getdwarf, to get mainbias and dwbias, respectively.
If mainbias == dwbias, you are already correct. To check for the bug,
you'd see if the original sym_addr and the sym_addr adjusted by
dwfl_module_relocate_address mainbias or by dwbias. But, if you just want
to work right rather than test for the bug, you can just do:
Dwarf_Addr save_addr = sym_addr;
int ki = dwfl_module_relocate_address (m, &sym_addr);
dwfl_assert ("dwfl_module_relocate_address", ki >= 0);
secname = dwfl_module_relocation_info (m, ki, NULL);
if (ki == 0 && secname != NULL && secname[0] == '\0')
{
Dwarf_Addr bias;
dwfl_assert ("dwfl_getelf", dwfl_module_getelf (m, &bias) != NULL);
sym_addr = save_addr - bias;
}
Thanks,
Roland
next prev parent reply other threads:[~2008-12-16 9:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-12 17:37 Mark Wielaard
2008-12-12 18:15 ` Mark Wielaard
2008-12-12 20:07 ` Roland McGrath
2008-12-15 12:07 ` Mark Wielaard
2008-12-15 13:42 ` Mark Wielaard
2008-12-16 9:12 ` Roland McGrath [this message]
2008-12-16 13:28 ` Mark Wielaard
2008-12-16 23:06 ` Roland McGrath
2008-12-17 15:37 ` Mark Wielaard
2008-12-18 0:00 ` Roland McGrath
2008-12-18 14:50 ` Mark Wielaard
2008-12-18 23:59 ` Roland McGrath
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=20081216091138.68D1FFC351@magilla.sf.frob.com \
--to=roland@redhat.com \
--cc=mjw@redhat.com \
--cc=systemtap@sources.redhat.com \
/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).