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

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

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 2211 bytes --]

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

[-- Attachment #2: solib-svr4.c.diff --]
[-- Type: text/plain, Size: 2862 bytes --]

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

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

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 2621 bytes --]

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


[-- Attachment #2: solib-svr4.c.diff --]
[-- Type: text/plain, Size: 2862 bytes --]

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

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

[Daniel Jacobowitz]

On Fri, Mar 07, 2008 at 10:41:21AM -0800, Joel Brobecker wrote:
> 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.

If anything I think you're underabusing them - we asked you to be a
global maintainer because we trusted your judgement :-)

> > 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.

This was what threw me off an immediate reply.  I doubt the kernel's
got a bug like this, since Solaris tools use the auxv data.  So we
must have an error when reading it.  Maybe the format is different
than we expect (32-bit vs 64-bit fields)?

Otherwise the patch looks fine.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Joel Brobecker]

> If anything I think you're underabusing them - we asked you to be a
> global maintainer because we trusted your judgement :-)

OK! :)

> > > 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.
> 
> This was what threw me off an immediate reply.  I doubt the kernel's
> got a bug like this, since Solaris tools use the auxv data.  So we
> must have an error when reading it.  Maybe the format is different
> than we expect (32-bit vs 64-bit fields)?

It's been a while, but I remember inspecting the memory contents
of what was supposed to be the AUXV region, and couldn't make any
sense out of it at the time, even after trying to change sizes
to 32bit or 64bit. If I get a chance, I'll look at it again.

> Otherwise the patch looks fine.

Thanks! I checked it in.

-- 
Joel

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

[Joel Brobecker]

> > This was what threw me off an immediate reply.  I doubt the kernel's
> > got a bug like this, since Solaris tools use the auxv data.  So we
> > must have an error when reading it.  Maybe the format is different
> > than we expect (32-bit vs 64-bit fields)?
> 
> It's been a while, but I remember inspecting the memory contents
> of what was supposed to be the AUXV region, and couldn't make any
> sense out of it at the time, even after trying to change sizes
> to 32bit or 64bit. If I get a chance, I'll look at it again.

Some additional data: I wasn't seeing this problem on neither our
Solaris 2.8 nor our 2.10 machine... Perhaps we're missing a patch
on our 2.9 machine. Not sure - I'll see if I can ask our sysadmin
to contact Sun about it.

-- 
Joel