This is the mail archive of the
mailing list for the binutils project.
Re: vdso handling
- From: Samuel Bronson <naesten at gmail dot com>
- To: binutils at sourceware dot org
- Cc: gdb at sourceware dot org
- Date: Sun, 01 Jun 2014 16:31:55 -0400
- Subject: Re: vdso handling
- Authentication-results: sourceware.org; auth=none
- References: <A78C989F6D9628469189715575E55B230AA884EB at IRSMSX104 dot ger dot corp dot intel dot com> <20140312071701 dot GW26922 at bubble dot grove dot modra dot org> <CADPb22SAmK5JB3muW_nCvuHN5L-aOcdyzYNR+OtnM3bA1x_OJg at mail dot gmail dot com> <CAHACq4o=HmdCo1FPFL-96raf2UN805jvM=VZM-9dbKrmzJFJTw at mail dot gmail dot com> <20140313010147 dot GZ26922 at bubble dot grove dot modra dot org> <A78C989F6D9628469189715575E55B230AA9CDCB at IRSMSX103 dot ger dot corp dot intel dot com> <5321834E dot 9000509 at redhat dot com> <53218C92 dot 9050303 at redhat dot com>
Pedro Alves <firstname.lastname@example.org> writes:
> 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
Hmm, why don't we already do that? It's bound to be easier than meeting
the conditions to get glibc to stop falsely cliaming that the vDSO comes
from a file <https://sourceware.org/bugzilla/show_bug.cgi?id=13097#c5>.
That'd be enough to take two bugs off of <http://bugs.debian.org/gdb>
> 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.
What versions don't list the vdso under some name or other? (Mine calls
it linux-gate.so.1 for some reason.)
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!