From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26316 invoked by alias); 1 Feb 2008 18:13:15 -0000 Received: (qmail 26300 invoked by uid 22791); 1 Feb 2008 18:13:13 -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, 01 Feb 2008 18:12:41 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id B77AE2A9D36 for ; Fri, 1 Feb 2008 13:12:39 -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 3ZgCNhVr-BqH for ; Fri, 1 Feb 2008 13:12:39 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 458E52A9D3A for ; Fri, 1 Feb 2008 13:12:39 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 2DCCDE7ACB; Fri, 1 Feb 2008 10:12:37 -0800 (PST) Date: Fri, 01 Feb 2008 18:13:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: [RFA] "continue" after "attach" fails on sparc64-solaris Message-ID: <20080201181237.GA20356@adacore.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline 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-02/txt/msg00026.txt.bz2 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 2211 Hello, 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 --TB36FDmn/VVEgNH/ 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 --TB36FDmn/VVEgNH/--