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

[Joel Brobecker]

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, &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