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: Roland McGrath <roland at redhat dot com>
- To: 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:32:20 -0700
- Subject: Re: unwind support for Linux 2.6 vsyscall DSO
> On Oct 9, 4:23pm, Daniel Jacobowitz wrote:
> > By the way, assuming I remember this correctly, the DSO will _also_
> > show up in the link map we get from the dynamic loader. Not sure how
> > that will influence things.
>
> If this entry is already present in the list of so_list structs (pointed
> at by ``so_list_head''), it shouldn't cause any problem. If it's not,
> an attempt will be made to load it. I'm not sure what the result of
> that will be.
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.)
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.