From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23732 invoked by alias); 10 May 2003 21:49:21 -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 23531 invoked from network); 10 May 2003 21:49:14 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.166.107) by sources.redhat.com with SMTP; 10 May 2003 21:49:14 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 1EB322B2F; Sat, 10 May 2003 17:48:59 -0400 (EDT) Message-ID: <3EBD73CA.10807@redhat.com> Date: Sat, 10 May 2003 21:49:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roland McGrath Cc: gdb@sources.redhat.com Subject: Re: gdb support for Linux vsyscall DSO References: <200305101942.h4AJgoe32699@magilla.sf.frob.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00192.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. > > > 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. It doesn't make it the wrong thing to do either. As they say, keep it simple. What was posted was a worryingly long list of changes for something that should be relatively straight forward - find the eh-frame stuff and use it. Any way, re-reading your post yes, the info is in there. If the address is known, GDB can pull the contents out of memory. Given the list of targets: - core - native attach - native run - remote - ?more? I believe the choices are: - find a way of determing that address across all of these targets :-/ - implement per-target custom mechanisms for pulling out this information (creating a need to test/implement each target separatly - vis the corefile + dwarf2 changes) :-// So, it possible to find the address (symbol?, /proc, shlib load table, ...?) for all targets? /proc/PID/map, on a remote, is a possability. A remote version of find_memory_regions() would be useful anyway - clean up gcore a bit. However, the down side is that a system with no /proc mounted wouldn't debug very well :-/ Andrew