From: Pedro Alves <palves@redhat.com>
To: "Metzger, Markus T" <markus.t.metzger@intel.com>
Cc: Alan Modra <amodra@gmail.com>, Cary Coutant <ccoutant@google.com>,
Doug Evans <dje@google.com>,
"gdb@sourceware.org" <gdb@sourceware.org>,
"binutils@sourceware.org" <binutils@sourceware.org>
Subject: Re: vdso handling
Date: Thu, 13 Mar 2014 10:46:00 -0000 [thread overview]
Message-ID: <53218C92.9050303@redhat.com> (raw)
In-Reply-To: <5321834E.9000509@redhat.com>
On 03/13/2014 10:07 AM, Pedro Alves wrote:
> Why's that? Why doesn't the memory-backed bfd paths take the same paths as
> a file-backed bfd internally in bfd? It sounds to me that this should be
> doable without duplication.
BTW, I meant that for vDSO's only. The vsyscall page is not an elf,
and therefore bfd still needs to be passed a template elf. For the
latter, GDB would indeed need to work with the segments. Do we still
care for vsyscall kernels? But for the former, bfd should just be
able to read the whole DSO as a plain elf.
Some glibc versions even include the vdso in the DSO list (*), and GDB
should be able to tell that that DSO is the vDSO (by matching addresses), and
load it completely from memory, still using a memory backed bfd, but _without_
a template. So with that in mind, bfd should be able to read the vdso
as a bfd from memory using the same paths as a file-backed bfd, except,
well, the bfd's backing store is in memory rather than in a file.
(*) note how linux-vdso.so.1 is listed by ldd, even if "info shared" in gdb
doesn't show it, on some systems.
--
Pedro Alves
next prev parent reply other threads:[~2014-03-13 10:46 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 [this message]
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
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=53218C92.9050303@redhat.com \
--to=palves@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