Native Solaris thread debugging is broken since 2006-01-24

Native Solaris thread debugging is broken since 2006-01-24

[Peter Schauer]

This change:

2006-01-24  Daniel Jacobowitz  <dan@codesourcery.com>

        * infcmd.c: Include "observer.h".
        (post_create_inferior): New function.
        (run_command_1): Call it.  Also call proceed.
        * inferior.h (post_create_inferior): New prototype.
        * Makefile.in (infcmd.o): Update.

        * gnu-nat.c (gnu_create_inferior): Don't call proceed.
        * go32-nat.c (go32_create_inferior): Likewise.
        * nto-procfs.c (procfs_create_inferior): Likewise.
        * procfs.c (procfs_create_inferior): Likewise.

breaks native Solaris thread debugging.

Using the pthreads testsuite case, before this change you get the
following with the commands
break main
run
info threads:

  6 Thread 3          0xdfa39657 in _swtch () from /usr/lib/libthread.so.1
  5 Thread 2 (LWP 2)  0xdfadb5a8 in _signotifywait () from /usr/lib/libc.so.1
* 4 Thread 1 (LWP 1)  main (argc=0x1, argv=0x8047874)
    at /users/pes/gdbnd/devo/gdb/testsuite/gdb.threads/pthreads.c:122
  3 LWP    3          0xdfa3a158 in _lwp_start () from /usr/lib/libthread.so.1
  2 LWP    2          0xdfadb5a8 in _signotifywait () from /usr/lib/libc.so.1
  1 LWP    1          main (argc=0x1, argv=0x8047874)
    at /users/pes/gdbnd/devo/gdb/testsuite/gdb.threads/pthreads.c:122

and after the change you get only:

  3 LWP 3  0xdfa3a158 in _lwp_start () from /usr/lib/libthread.so.1
  2 LWP 2  0xdfadb5a8 in _signotifywait () from /usr/lib/libc.so.1
* 1 LWP 1  main (argc=0x1, argv=0x8047874)
    at /users/pes/gdbnd/devo/gdb/testsuite/gdb.threads/pthreads.c:12

Here is the reason for the failure:
static void
sol_thread_create_inferior (char *exec_file, char *allargs, char **env,
                            int from_tty)
{
  procfs_ops.to_create_inferior (exec_file, allargs, env, from_tty);

  if (sol_thread_active && !ptid_equal (inferior_ptid, null_ptid))
    {
      /* Save for xfer_memory.  */
      main_ph.ptid = inferior_ptid;

      push_target (&sol_thread_ops);

Before the change, procfs_ops.to_create_inferior called proceed, which took
the execution till the breakpoint at main.
This caused the shared libraries to be read in as a side effect, and
sol_thread_active was set via the sol_thread_new_objfile hook, after
libthread.so was read in.

With the removed proceed call, the shared libraries are read in much later,
sol_thread_active is not yet set in the above code, and the sol_thread_ops
target is never pushed, causing user level thread debugging to fail.

A lightly tested patch along the lines of linux-thread-db.c is included
below, it brings the testsuite results for the threads tests back to
the behaviour in gdb-6.4, but I do not have enough spare time to follow
this through on gdb-patches.

As I doubt that this can be fixed in time for gdb-6.5, I suggest that
an appropriate NEWS entry for this issue should be created,
to save Solaris users from grief after upgrading to 6.5.

--- sol-thread.c.orig	2006-05-23 18:06:45.000000000 +0200
+++ sol-thread.c	2006-05-27 13:39:00.550131000 +0200
@@ -356,18 +356,6 @@ sol_thread_attach (char *args, int from_
   /* Must get symbols from shared libraries before libthread_db can run!  */
   solib_add (NULL, from_tty, (struct target_ops *) 0, auto_solib_add);
 
-  if (sol_thread_active)
-    {
-      printf_filtered ("sol-thread active.\n");
-      main_ph.ptid = inferior_ptid; /* Save for xfer_memory.  */
-      push_target (&sol_thread_ops);
-      inferior_ptid = lwp_to_thread (inferior_ptid);
-      if (PIDGET (inferior_ptid) == -1)
-	inferior_ptid = main_ph.ptid;
-      else
-	add_thread (inferior_ptid);
-    }
-
   /* FIXME: Might want to iterate over all the threads and register
      them.  */
 }
@@ -384,6 +372,7 @@ sol_thread_detach (char *args, int from_
 {
   inferior_ptid = pid_to_ptid (PIDGET (main_ph.ptid));
   unpush_target (&sol_thread_ops);
+  sol_thread_active = 0;
   procfs_ops.to_detach (args, from_tty);
 }
 
@@ -756,21 +745,6 @@ sol_thread_create_inferior (char *exec_f
 			    int from_tty)
 {
   procfs_ops.to_create_inferior (exec_file, allargs, env, from_tty);
-
-  if (sol_thread_active && !ptid_equal (inferior_ptid, null_ptid))
-    {
-      /* Save for xfer_memory.  */
-      main_ph.ptid = inferior_ptid;
-
-      push_target (&sol_thread_ops);
-
-      inferior_ptid = lwp_to_thread (inferior_ptid);
-      if (PIDGET (inferior_ptid) == -1)
-	inferior_ptid = main_ph.ptid;
-
-      if (!in_thread_list (inferior_ptid))
-	add_thread (inferior_ptid);
-    }
 }
 
 /* This routine is called whenever a new symbol table is read in, or
@@ -822,7 +796,21 @@ sol_thread_new_objfile (struct objfile *
       goto quit;
     }
 
-  sol_thread_active = 1;
+  if (!sol_thread_active && !ptid_equal (inferior_ptid, null_ptid))
+    {
+      /* Save for xfer_memory.  */
+      main_ph.ptid = inferior_ptid;
+
+      push_target (&sol_thread_ops);
+      sol_thread_active = 1;
+
+      inferior_ptid = lwp_to_thread (inferior_ptid);
+      if (PIDGET (inferior_ptid) == -1)
+	inferior_ptid = main_ph.ptid;
+
+      if (!in_thread_list (inferior_ptid))
+	add_thread (inferior_ptid);
+    }
 
 quit:
   /* Call predecessor on chain, if any.  */
@@ -836,6 +824,7 @@ static void
 sol_thread_mourn_inferior (void)
 {
   unpush_target (&sol_thread_ops);
+  sol_thread_active = 0;
   procfs_ops.to_mourn_inferior ();
 }
 

-- 
Peter Schauer			Peter.Schauer@mytum.de

Re: Native Solaris thread debugging is broken since 2006-01-24

[Joel Brobecker]

Hello all,

>         * infcmd.c: Include "observer.h".
>         (post_create_inferior): New function.
>         (run_command_1): Call it.  Also call proceed.
>         * inferior.h (post_create_inferior): New prototype.
>         * Makefile.in (infcmd.o): Update.
> 
>         * gnu-nat.c (gnu_create_inferior): Don't call proceed.
>         * go32-nat.c (go32_create_inferior): Likewise.
>         * nto-procfs.c (procfs_create_inferior): Likewise.
>         * procfs.c (procfs_create_inferior): Likewise.
> 
> breaks native Solaris thread debugging.

FYI: I have created threads/2137 to report this problem. I will use
that number to document this problem.

-- 
Joel