Re: gdb support for Linux vsyscall DSO

[Roland McGrath <roland@redhat.com>]

For some reason I didn't see Andrew's message in my mailbox, though I see
it in the mailing list archives (I'm not on the mailing list myself).


> On Sat, May 10, 2003 at 01:24:39PM -0400, Andrew Cagney wrote:
> > Roland,
> > 
> > How exactly does this vsyscall memory region(1) come to be?  For 
> > instance, how does GLIBC come to know where it is - GLIBC would need the 
> > region's address to perform a syscall to find the regions address.  If 
> > the underlying mechanism is explained (this is far from a tranditional 
> > lib*.so), GDB developers will be in a better position to judge the best 
> > way of handling this.
> 
> It's created initially by the kernel, and its address is passed via the
> auxilliary vector on the stack, and read by ld.so.  Roland explained
> later in his essay about some ways to get at the aux vector.

The memory is always there.  As I explained near the end of my long
message, the kernel tells the program where to find it with the
AT_SYSINFO_EHDR (and AT_SYSINFO, which is now redundant) elements in the
aux vector on the stack at at startup.

The glibc dynamic linker code sets up its own data structures for the
vsyscall DSO as if it had been mapped itself.  There is no special case in
glibc that points at the eh_frame info.  Exception handling in libgcc
already uses a dynamic linker callback to see the phdrs of all DSOs in core
and follow their PT_GNU_EH_FRAME pointers.  The vsyscall DSO's eh_frame
info is found by this mechanism like other DSOs' are.  

> > Is there, for instance, anything to prevent GDB locating the symbol (in 
> > GLIBC) that points at the vsyscall area and then using that?  Similar 
> > for any mapped in eh_frame region.  Assuming that GDB has a well defined 
> > trigger point for knowing when the symbol can be referenced - but GDB 
> > would need that anyway.

Nothing prevents it but class.  The vsyscall DSO is a Linux kernel feature,
not a glibc feature.  It isn't proper layering for the support for it to
depend on glibc internals.  There are any number of things that could be
done simpler by presuming the form of glibc internals and requiring they be
there.  That doesn't make them the right things to do.


I said "the purpose of the vsyscall DSO for me is to make the gdb support
possible".  Perhaps that gave the wrong impression.  The gdb issue is what
made me personally really interested in implementing it, but was only one
of many factors leading to the choice of having an ELF DSO image provided
by the kernel.  The DSO plan is here to stay and does not exist solely for
the benefit of gdb.


Thanks,
Roland