This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: unwind support for Linux 2.6 vsyscall DSO
- From: Kevin Buettner <kevinb at redhat dot com>
- To: Roland McGrath <roland at redhat dot com>, Kevin Buettner <kevinb at redhat dot com>
- Cc: Daniel Jacobowitz <drow at mvista dot com>, Jim Blandy <jimb at redhat dot com>, Elena Zannoni <ezannoni at redhat dot com>, gdb-patches at sources dot redhat dot com
- Date: Thu, 9 Oct 2003 15:46:43 -0700
- Subject: Re: unwind support for Linux 2.6 vsyscall DSO
- References: <200310092232.h99MWK8r013186@magilla.sf.frob.com>
On Oct 9, 3:32pm, Roland McGrath wrote:
> It will appear in the dynamic linker's list of objects, but will not have a
> file name. (Actually, a bogus patch from Dan went into glibc that makes it
> report its soname as file name, but I'm fixing that.) The file name in
> l_name will be an empty string. (With the broken glibc of the moment, it
> reports "linux-gate.so.1", a file that exists nowhere and never will.)
Is there any reason there couldn't be a /proc/PID entry for this file?
(My apologies if this has already been discussed ad nauseum. I
haven't really been paying attention up 'til now.)
> There is no way for you to associate this record with the implicit DSO.
> All the information you have is the (empty) name and an l_addr of zero
> (because the kernel-supplied DSO is effectively "prelinked" to its address).
> So, I think that will not actually interfere since it will appear to be
> some bogon.
Okay.
Kevin