Re: gdb support for Linux vsyscall DSO

[Daniel Jacobowitz <drow at mvista dot com>]

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.

> 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.
> 
> This would eliminate the need to store all this elf header stuff in the 
> Kernel, let GDB confine any changes to a single linux-tdep.c file, and 
> even work remotely or with a core file.

The down side is that this is then glibc specific... the mechanism
isn't glibc's.  I think that's Roland's intention at least.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer