From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2654 invoked by alias); 7 Mar 2008 18:42:01 -0000 Received: (qmail 2638 invoked by uid 22791); 7 Mar 2008 18:41:59 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Mar 2008 18:41:26 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 108032AA485 for ; Fri, 7 Mar 2008 13:41:24 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dr2F4GgmkQzD for ; Fri, 7 Mar 2008 13:41:23 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 8D9062AA482 for ; Fri, 7 Mar 2008 13:41:23 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 70624E7ACB; Fri, 7 Mar 2008 10:41:21 -0800 (PST) Date: Fri, 07 Mar 2008 18:42:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: Re: [RFA] "continue" after "attach" fails on sparc64-solaris Message-ID: <20080307184121.GB3892@adacore.com> References: <20080201181237.GA20356@adacore.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="5/uDoXvLw7AC5HRs" Content-Disposition: inline In-Reply-To: <20080201181237.GA20356@adacore.com> User-Agent: Mutt/1.4.2.2i 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: 2008-03/txt/msg00051.txt.bz2 --5/uDoXvLw7AC5HRs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 2621 This one is relatively straightforward, I think. I could commit it in a week or so unless there are objections, but I am afraid that it might be priviledge abuse (and I welcome feedback). Since it's been out for review for a while, I'll wait another week before checking it in. But do let me know if I'm abusing my priviledges. > I finally got a chance to look into something that Daniel hinted at > a while ago, when I modified solib-svr4.c to use the AT_BASE entry of > the auxiliary vector in order to find the base load address. > > The problem was the following: > > (gdb) attach ... > (gdb) c > Continuing. > Warning: > Cannot insert breakpoint -1. > Error accessing memory address 0xff36159c: I/O error. > > I fixed the problem by implementing a suggestion to use the AT_BASE > attributed, but as it turns out, this was only good enough for sparc32. > As far as I can tell, the auxilliary data obtained when running a 64bit > app looks screwed. So we still have the same problem on sparc64. > Surprisingly, it seems to affect only multi-threaded programs. > > Daniel said in http://www.sourceware.org/ml/gdb-patches/2007-09/msg00206.html: > > > So, it has attached to the program and decided that it's at the start > > address. That means we tried this: > > > > /* On a running target, we can get the dynamic linker's base > > address from the shared library table. */ > > solib_add (NULL, 0, ¤t_target, auto_solib_add); > > so = master_so_list (); > > while (so) > > ... > > > > and did not find any loaded libraries or else did not find the > > interpreter in the list. That's strange and almost certainly > > indicates a bug that we should fix. The loader should have > > been in the list at that point. Maybe it has a different > > filename in the list than in .interp? > > And indeed, the name of the loader changes from /usr/lib/sparcv9/ld.so.1 > (in .interp) to /lib/sparcv9/ld.so.1. > > I took advantage of Volodya's work: Extracted out the work of comparing > shared library names, extended it to recognize the sparc64 case, and > then change the string-compare into a call to our specialized comparison > routine. 2008-02-01 Joel Brobecker * solib-svr4.c (svr4_same_1): New function, originally extracted from svr4_same and expanded to handle the sparc64 case. (svr4_same): Move up and reimplement using svr4_same_1. (enable_break): Use svr4_same_1 to do shared library name comparisons. Tested on sparc64-solaris2.9. No regression. OK to apply? Thanks, -- Joel --5/uDoXvLw7AC5HRs Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="solib-svr4.c.diff" Content-length: 2862 Index: solib-svr4.c =================================================================== RCS file: /cvs/src/src/gdb/solib-svr4.c,v retrieving revision 1.82 diff -u -p -r1.82 solib-svr4.c --- solib-svr4.c 29 Jan 2008 21:11:24 -0000 1.82 +++ solib-svr4.c 1 Feb 2008 17:39:56 -0000 @@ -103,6 +103,40 @@ static char *main_name_list[] = NULL }; +/* Return non-zero if GDB_SO_NAME and INFERIOR_SO_NAME represent + the same shared library. */ + +static int +svr4_same_1 (const char *gdb_so_name, const char *inferior_so_name) +{ + if (strcmp (gdb_so_name, inferior_so_name) == 0) + return 1; + + /* On Solaris, when starting inferior we think that dynamic linker is + /usr/lib/ld.so.1, but later on, the table of loaded shared libraries + contains /lib/ld.so.1. Sometimes one file is a link to another, but + sometimes they have identical content, but are not linked to each + other. We don't restrict this check for Solaris, but the chances + of running into this situation elsewhere are very low. */ + if (strcmp (gdb_so_name, "/usr/lib/ld.so.1") == 0 + && strcmp (inferior_so_name, "/lib/ld.so.1") == 0) + return 1; + + /* Similarly, we observed the same issue with sparc64, but with + different locations. */ + if (strcmp (gdb_so_name, "/usr/lib/sparcv9/ld.so.1") == 0 + && strcmp (inferior_so_name, "/lib/sparcv9/ld.so.1") == 0) + return 1; + + return 0; +} + +static int +svr4_same (struct so_list *gdb, struct so_list *inferior) +{ + return (svr4_same_1 (gdb->so_original_name, inferior->so_original_name)); +} + /* link map access functions */ static CORE_ADDR @@ -1032,7 +1066,7 @@ enable_break (void) so = master_so_list (); while (so) { - if (strcmp (buf, so->so_original_name) == 0) + if (svr4_same_1 (buf, so->so_original_name)) { load_addr_found = 1; loader_found_in_list = 1; @@ -1569,25 +1603,6 @@ elf_lookup_lib_symbol (const struct objf (objfile, name, linkage_name, domain, symtab); } -static int -svr4_same (struct so_list *gdb, struct so_list *inferior) -{ - if (! strcmp (gdb->so_original_name, inferior->so_original_name)) - return 1; - - /* On Solaris, when starting inferior we think that dynamic linker is - /usr/lib/ld.so.1, but later on, the table of loaded shared libraries - contains /lib/ld.so.1. Sometimes one file is a link to another, but - sometimes they have identical content, but are not linked to each - other. We don't restrict this check for Solaris, but the chances - of running into this situation elsewhere are very low. */ - if (strcmp (gdb->so_original_name, "/usr/lib/ld.so.1") == 0 - && strcmp (inferior->so_original_name, "/lib/ld.so.1") == 0) - return 1; - - return 0; -} - extern initialize_file_ftype _initialize_svr4_solib; /* -Wmissing-prototypes */ void --5/uDoXvLw7AC5HRs--