Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Mark Wielaard <mjw@redhat.com>
To: Alan Modra <amodra@gmail.com>
Cc: Cary Coutant <ccoutant@google.com>, Doug Evans <dje@google.com>,
	       "Metzger, Markus T" <markus.t.metzger@intel.com>,
	       "gdb@sourceware.org" <gdb@sourceware.org>,
	       "binutils@sourceware.org" <binutils@sourceware.org>
Subject: Re: vdso handling
Date: Thu, 13 Mar 2014 14:38:00 -0000	[thread overview]
Message-ID: <1394721476.11818.128.camel@bordewijk.wildebeest.org> (raw)
In-Reply-To: <20140313130322.GA3384@bubble.grove.modra.org>

On Thu, 2014-03-13 at 23:33 +1030, Alan Modra wrote:
> On Thu, Mar 13, 2014 at 10:52:16AM +0100, Mark Wielaard wrote:
> > On Thu, 2014-03-13 at 11:31 +1030, Alan Modra wrote:
> > > It wouldn't
> > > help in the vdso case anyway, since the problem there is that you only
> > > have the loaded part of the original ELF file.
> > 
> > Note that the vdso is often special, compared to other ELF dsos, because
> > the loaded part is just the complete ELF image in memory. Since they are
> > very simple they will just have one PT_LOAD at offset zero and if the
> > image is smaller than the page size then the whole file is just simply
> > mapped into memory completely. So by fetching the vdso ELF image from
> > remote memory you should be able to get the section headers and the
> > not-allocated sections too.
> 
> Yes, but if the vdso does not fit in a page (which incidentally is
> inferred by program header p_align), then you may lose the section
> headers.  I was assuming this was the case.

Yes, you are right. Almost everything else is bigger than a page and has
multiple PT_LOAD segments. In which case determining whether the full
shdrs were mapped in from the file is much trickier. And might have to
rely on only the phdrs.

We recently went through this for elfutils, which also contains an
elf_from_remote_memory implementation (if someone needs inspiration).
Currently that implementation just uses the phdrs and so needs some
heuristics using the program header fields to know what part of the file
was mapped where. But if you have access to the actual /proc/PID/maps
ranges you might be able to do something more accurate, or at least be
able to cross check that the program headers view is really how the ELF
image is actually laid out (*).

Cheers,

Mark

(*) Don't make the mistake we made to think p_align is what segments are
actually aligned to, the dynamic loader on GNU/Linux just uses the
actual page size of the architecture to align the mappings:
https://lists.fedorahosted.org/pipermail/elfutils-devel/2014-March/003859.html



  reply	other threads:[~2014-03-13 14:38 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-10 13:05 Metzger, Markus T
2014-03-12  7:17 ` Alan Modra
2014-03-12 11:31   ` Mike Frysinger
2014-03-12 17:34   ` Doug Evans
2014-03-12 20:23     ` Cary Coutant
2014-03-13  1:01       ` Alan Modra
2014-03-13  8:25         ` Metzger, Markus T
2014-03-13  9:48           ` Metzger, Markus T
2014-03-13 10:07           ` Pedro Alves
2014-03-13 10:46             ` Pedro Alves
2014-06-01 20:32               ` Samuel Bronson
2014-06-06 12:45                 ` Pedro Alves
2014-03-13 13:13             ` Alan Modra
2014-03-13  9:52         ` Mark Wielaard
2014-03-13 13:03           ` Alan Modra
2014-03-13 14:38             ` Mark Wielaard [this message]
2014-03-13 14:59             ` Pedro Alves
2014-03-13 15:04               ` Pedro Alves
2014-03-13 15:26                 ` Pedro Alves
2014-03-13 23:53                   ` Alan Modra
2014-03-18 15:14                     ` Metzger, Markus T
2014-03-18 23:10                       ` Alan Modra
2014-03-19  8:11                         ` Metzger, Markus T
2014-03-19  8:31                         ` Metzger, Markus T
2014-03-19 12:04                           ` Pedro Alves
2014-03-20  2:00                           ` Alan Modra
2014-03-21 15:55                             ` Pedro Alves
2014-03-26  9:32                               ` Metzger, Markus T
2014-03-19 12:03                         ` Pedro Alves
2014-03-20  1:33                           ` Alan Modra
2014-03-21  8:10                             ` Metzger, Markus T
2014-03-21 15:48                             ` Pedro Alves

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=1394721476.11818.128.camel@bordewijk.wildebeest.org \
    --to=mjw@redhat.com \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=ccoutant@google.com \
    --cc=dje@google.com \
    --cc=gdb@sourceware.org \
    --cc=markus.t.metzger@intel.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