From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1539 invoked by alias); 10 May 2003 18:13:53 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 1525 invoked from network); 10 May 2003 18:13:53 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 10 May 2003 18:13:53 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19EYrQ-0006In-00; Sat, 10 May 2003 13:14:16 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19EYqy-0003m0-00; Sat, 10 May 2003 14:13:48 -0400 Date: Sat, 10 May 2003 18:13:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Roland McGrath , Mark Kettenis , gdb@sources.redhat.com Subject: Re: gdb support for Linux vsyscall DSO Message-ID: <20030510181348.GA14436@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Roland McGrath , Mark Kettenis , gdb@sources.redhat.com References: <200305100707.h4A777T29932@magilla.sf.frob.com> <3EBD35D7.2030207@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EBD35D7.2030207@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-05/txt/msg00187.txt.bz2 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