From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7490 invoked by alias); 10 May 2003 19:42:52 -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 7434 invoked from network); 10 May 2003 19:42:51 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.163.213.212) by sources.redhat.com with SMTP; 10 May 2003 19:42:51 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id DC26E354C; Sat, 10 May 2003 12:42:50 -0700 (PDT) Received: (from roland@localhost) by magilla.sf.frob.com (8.11.6/8.11.6) id h4AJgoe32699; Sat, 10 May 2003 12:42:50 -0700 Date: Sat, 10 May 2003 19:42:00 -0000 Message-Id: <200305101942.h4AJgoe32699@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: gdb support for Linux vsyscall DSO In-Reply-To: Daniel Jacobowitz's message of Saturday, 10 May 2003 14:13:48 -0400 <20030510181348.GA14436@nevyn.them.org> X-Antipastobozoticataclysm: When George Bush projectile vomits antipasto on the Japanese. X-SW-Source: 2003-05/txt/msg00189.txt.bz2 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