[RFA] "continue" after "attach" fails on sparc64-solaris

Joel Brobecker brobecker@adacore.com
Fri Feb 1 18:13:00 GMT 2008


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, &current_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  <brobecker@adacore.com>

        * 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
-------------- next part --------------
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


More information about the Gdb-patches mailing list