Re: gdb support for Linux vsyscall DSO

[Andrew Cagney <ac131313@redhat.com>]

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.

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.

However, before anyone tries to run with such ideas, what's really going on?

enjoy,
Andrew