public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: elfutils-devel@lists.fedorahosted.org
Subject: Re: [patch] Fix report_r_debug for prelinked libraries
Date: Sun, 27 Jul 2014 22:53:58 +0200	[thread overview]
Message-ID: <20140727205358.GA6635@toonder.wildebeest.org> (raw)
In-Reply-To: 20140724185028.GA13828@host2.jankratochvil.net

[-- Attachment #1: Type: text/plain, Size: 2250 bytes --]

On Thu, Jul 24, 2014 at 08:50:28PM +0200, Jan Kratochvil wrote:
> eu-stack: "Callback returned failure" for seemingly OK shared libraries
> https://bugzilla.redhat.com/show_bug.cgi?id=1112610#c2
> 
> attaching the fix.  I find it obviously right.
> It also has no testsuite regressions.
> 
> The problem was that user dumping the core file had DSOs prelinked but
> downloaded DSOs from RPMs are not prelinked.  l_addr is then zero but it
> cannot be determined from the DSO file.

Right. I admit it wasn't immediately obvious to me. It is obvious once
you realize that l_addr is the difference between runtime addresses and
ELF file at the time of core dump. But the link_map code might use a
differently pre-linked version of that ELF file. And you can recalculate
that difference by using l_ld from the core file and elf_dynamic_vaddr
from the current ELF file phdrs, which both point to the dynamic section.

> Unfortunately I do not provide a testcase.  It fixes the Bug above as tested
> on its core file but I cannot disclose the core file (or its parts).
> And despite I did try I haven't reproduced it by a hand-made testcase.
>
> The problem is the modules placing code got overcomplicated and IMO it could
> be simplified one day.  There is the former placement which works somehow and
> there is the placement by patches of mine which force it here and there to the
> right positions.  Trying to exploit failure of the add-on code of mine always
> ended up on the former code placing it right on its own.

Thanks for trying. I am convinced of the solution even without a testcase.

Just one nitpick with the following comment:
>  
> -      GElf_Addr l_addr = addrs[0];
> +      // unused:
> +      // GElf_Addr l_addr = addrs[0];
>        GElf_Addr l_name = addrs[1];
>        GElf_Addr l_ld = addrs[2];

Could you expand that comment a little to say why it is unused and why we
need to recalculate it? Maybe "Unused: l_addr is the difference between
the address in memory and the ELF file when the core was created. We need
to recalculate the difference below because the ELF file we use might be
differently pre-linked." Or something similar.

OK with an expanded comment.

Thanks,

Mark

             reply	other threads:[~2014-07-27 20:53 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-27 20:53 Mark Wielaard [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-07-24 18:50 Jan Kratochvil

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=20140727205358.GA6635@toonder.wildebeest.org \
    --to=mark@klomp.org \
    --cc=elfutils-devel@lists.fedorahosted.org \
    /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).