This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb support for Linux vsyscall DSO
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: Roland McGrath <roland at redhat dot com>
- Cc: Mark Kettenis <kettenis at chello dot nl>, gdb at sources dot redhat dot com
- Date: Sat, 10 May 2003 13:24:39 -0400
- Subject: Re: gdb support for Linux vsyscall DSO
- References: <200305100707.h4A777T29932@magilla.sf.frob.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