From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14073 invoked by alias); 27 Mar 2007 18:25:15 -0000 Received: (qmail 14060 invoked by uid 22791); 27 Mar 2007 18:25:14 -0000 X-Spam-Check-By: sourceware.org Received: from return.false.org (HELO return.false.org) (66.207.162.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 27 Mar 2007 19:25:05 +0100 Received: from return.false.org (localhost [127.0.0.1]) by return.false.org (Postfix) with ESMTP id AED554B271; Tue, 27 Mar 2007 13:25:03 -0500 (CDT) Received: from caradoc.them.org (dsl093-172-095.pit1.dsl.speakeasy.net [66.93.172.95]) by return.false.org (Postfix) with ESMTP id 633B64B270; Tue, 27 Mar 2007 13:25:03 -0500 (CDT) Received: from drow by caradoc.them.org with local (Exim 4.63) (envelope-from ) id 1HWGLu-0007Us-U8; Tue, 27 Mar 2007 14:25:02 -0400 Date: Tue, 27 Mar 2007 18:25:00 -0000 From: Daniel Jacobowitz To: Fred Fish Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] - Patch for 32-bit x86 corefiles read by 64 bit gdb Message-ID: <20070327182502.GA28164@caradoc.them.org> Mail-Followup-To: Fred Fish , gdb-patches@sources.redhat.com References: <200703051053.25514.fnf@specifix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200703051053.25514.fnf@specifix.com> User-Agent: Mutt/1.5.14+cvs20070313 (2007-03-13) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-03/txt/msg00259.txt.bz2 On Mon, Mar 05, 2007 at 10:53:25AM -0700, Fred Fish wrote: > Notice the warning: > > warning: Can't read pathname for load map: Input/output error. > > The problem here is that there is an extra shared object referenced in > the dynamic linker's list, for which the actual name string is located > in the address space of one of the other two libraries that haven't > been loaded yet. So gdb doesn't know how to find the name string. It > gives I/O error as it's generic response to being asked to read an > unmapped address. > > Interestingly, once you've loaded libc and ld-linux.so, you can access > that address, but there is a null string there. The address is also > the same address as the first entry in the list, which is for the > main program, and is skipped during the building of gdb's internal > list of shared objects. > > I've not dug far enough to know what this extra unnamed object is. > But is seems intuitive that if it has the same address for the name > string as the first (skipped) object, it should probably be skipped > also. (gdb) set $l = (struct link_map *)0xf7fff4f8 (gdb) p *$l $4 = {l_addr = 0, l_name = 0xf7ffcc56 "", l_ld = 0x8049474, l_next = 0xf7fe8838, l_prev = 0x0} (gdb) p *$l.l_next $5 = {l_addr = 0, l_name = 0xf7ffcc56 "", l_ld = 0xffffe744, l_next = 0xf7fe8ab0, l_prev = 0xf7fff4f8} (gdb) p *$l.l_next.l_next The object is in the top page of virtual memory; therefore it is the kernel-supplied vDSO. They have the same name because they come from these calls: /* Create a link_map for the executable itself. This will be what dlopen on "" returns. */ main_map = _dl_new_object ((char *) "", "", lt_executable, NULL, __RTLD_OPENEXEC, LM_ID_BASE); ... /* Set up the data structures for the system-supplied DSO early, so they can influence _dl_init_paths. */ if (GLRO(dl_sysinfo_dso) != NULL) { /* Do an abridged version of the work _dl_map_object_from_fd would do to map in the object. It's already mapped and prelinked (and better be, since it's read-only and so we couldn't relocate it). We just want our data structures to describe it as if we had just mapped and relocated it normally. */ struct link_map *l = _dl_new_object ((char *) "", "", lt_library, NULL, 0, LM_ID_BASE); GCC and GNU ld optimize the empty string so that ld.so only has one copy. So, you're basically getting lucky. Therefore I think your patch is not correct. It would be nice to find another way to get rid of the warning, though. Does the warning add value in any reasonably likely situation? If something has scribbled on the shared library list, the next/prev pointers are more likely to be bad. -- Daniel Jacobowitz CodeSourcery