From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 498 invoked by alias); 9 Oct 2003 22:32:24 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 485 invoked from network); 9 Oct 2003 22:32:22 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sources.redhat.com with SMTP; 9 Oct 2003 22:32:22 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 8D95D357B; Thu, 9 Oct 2003 15:32:21 -0700 (PDT) Received: from magilla.sf.frob.com (localhost.localdomain [127.0.0.1]) by magilla.sf.frob.com (8.12.9/8.12.9) with ESMTP id h99MWLN2013190; Thu, 9 Oct 2003 15:32:21 -0700 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.9/8.12.9/Submit) id h99MWK8r013186; Thu, 9 Oct 2003 15:32:20 -0700 Date: Thu, 09 Oct 2003 22:32:00 -0000 Message-Id: <200310092232.h99MWK8r013186@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Kevin Buettner Cc: Daniel Jacobowitz , Jim Blandy , Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO In-Reply-To: Kevin Buettner's message of Thursday, 9 October 2003 13:46:36 -0700 <1031009204636.ZM14370@localhost.localdomain> X-Shopping-List: (1) Disheveled digression harmonizers (2) Juvenile flatulent carrion (3) Raucous dividers X-SW-Source: 2003-10/txt/msg00327.txt.bz2 > On Oct 9, 4:23pm, Daniel Jacobowitz wrote: > > By the way, assuming I remember this correctly, the DSO will _also_ > > show up in the link map we get from the dynamic loader. Not sure how > > that will influence things. > > If this entry is already present in the list of so_list structs (pointed > at by ``so_list_head''), it shouldn't cause any problem. If it's not, > an attempt will be made to load it. I'm not sure what the result of > that will be. It will appear in the dynamic linker's list of objects, but will not have a file name. (Actually, a bogus patch from Dan went into glibc that makes it report its soname as file name, but I'm fixing that.) The file name in l_name will be an empty string. (With the broken glibc of the moment, it reports "linux-gate.so.1", a file that exists nowhere and never will.) There is no way for you to associate this record with the implicit DSO. All the information you have is the (empty) name and an l_addr of zero (because the kernel-supplied DSO is effectively "prelinked" to its address). So, I think that will not actually interfere since it will appear to be some bogon.