RFC: Initialize libthread_db at the right time

RFC: Initialize libthread_db at the right time

[Daniel Jacobowitz]

We've had some recurring problems debugging statically linked executables
using libthread_db; this patch is the first of several fixes for that.
This doesn't do much; it just splits the check out from the new_objfile
hook, and calls it from target_post_attach and target_post_startup_inferior
in the Linux native target.

Earlier versions of this patch used an observer instead, which was silly
of me; we only want to do this when we're sitting on top of the Linux
native target, not when we're on top of e.g. the remote target.  This
mostly fixes the not-enabling-libthread_db-when-we-should-be class of
problems; there's still one gross hack in remote.c which avoids
calling the new objfile hook for remote targets, but that's a mess
for another day.

Any comments?  Otherwise, I'll commit this in a few days.  It handles
LinuxThreads, but NPTL needs a little push (coming up next).

-- 
Daniel Jacobowitz
CodeSourcery

2006-02-27  Daniel Jacobowitz  <dan@codesourcery.com>

	* linux-thread-db.c: Include "linux-nat.h".
	(check_for_thread_db): New function, split out from
	thread_db_new_objfile.  Remove dead check for active
	thread_db on inapplicable targets.
	(thread_db_new_objfile): Call check_for_thread_db.
	* Makefile.in (linux-thread-db.o): Update.
	* linux-nat.c (child_post_attach): Call check_for_thread_db.
	(linux_child_post_startup_inferior): Likewise.
	(lin_lwp_attach_lwp): Call target_post_attach instead of
	child_post_attach.
	* linux-nat.h (check_for_thread_db): New prototype.

Index: src/gdb/linux-thread-db.c
===================================================================
--- src.orig/gdb/linux-thread-db.c	2006-02-27 12:44:41.000000000 -0500
+++ src/gdb/linux-thread-db.c	2006-02-27 14:36:30.000000000 -0500
@@ -37,6 +37,7 @@
 #include "regcache.h"
 #include "solib-svr4.h"
 #include "gdbcore.h"
+#include "linux-nat.h"
 
 #ifdef HAVE_GNU_LIBC_VERSION_H
 #include <gnu/libc-version.h>
@@ -626,59 +627,49 @@ check_thread_signals (void)
 #endif
 }
 
-static void
-thread_db_new_objfile (struct objfile *objfile)
+/* Check whether thread_db is usable.  This function is called when
+   an inferior is created (or otherwise acquired, e.g. attached to)
+   and when new shared libraries are loaded into a running process.  */
+
+void
+check_for_thread_db (void)
 {
   td_err_e err;
+  static int already_loaded;
 
   /* First time through, report that libthread_db was successfuly
      loaded.  Can't print this in in thread_db_load as, at that stage,
-     the interpreter and it's console haven't started.  The real
-     problem here is that libthread_db is loaded too early - it should
-     only be loaded when there is a program to debug.  */
-  {
-    static int dejavu;
-    if (!dejavu)
-      {
-	Dl_info info;
-	const char *library = NULL;
-	/* Try dladdr.  */
-	if (dladdr ((*td_ta_new_p), &info) != 0)
-	  library = info.dli_fname;
-	/* Try dlinfo?  */
-	if (library == NULL)
-	  /* Paranoid - don't let a NULL path slip through.  */
-	  library = LIBTHREAD_DB_SO;
-	printf_unfiltered (_("Using host libthread_db library \"%s\".\n"),
-			   library);
-	dejavu = 1;
-      }
-  }
+     the interpreter and it's console haven't started.  */
 
-  /* Don't attempt to use thread_db on targets which can not run
-     (core files).  */
-  if (objfile == NULL || !target_has_execution)
+  if (!already_loaded)
     {
-      /* All symbols have been discarded.  If the thread_db target is
-         active, deactivate it now.  */
-      if (using_thread_db)
-	{
-	  gdb_assert (proc_handle.pid == 0);
-	  unpush_target (&thread_db_ops);
-	  using_thread_db = 0;
-	}
+      Dl_info info;
+      const char *library = NULL;
+      if (dladdr ((*td_ta_new_p), &info) != 0)
+	library = info.dli_fname;
+
+      /* Try dlinfo?  */
+
+      if (library == NULL)
+	/* Paranoid - don't let a NULL path slip through.  */
+	library = LIBTHREAD_DB_SO;
 
-      goto quit;
+      printf_unfiltered (_("Using host libthread_db library \"%s\".\n"),
+			 library);
+      already_loaded = 1;
     }
 
   if (using_thread_db)
     /* Nothing to do.  The thread library was already detected and the
        target vector was already activated.  */
-    goto quit;
+    return;
 
-  /* Initialize the structure that identifies the child process.  Note
-     that at this point there is no guarantee that we actually have a
-     child process.  */
+  /* Don't attempt to use thread_db on targets which can not run
+     (executables not running yet, core files) for now.  */
+  if (!target_has_execution)
+    return;
+
+  /* Initialize the structure that identifies the child process.  */
   proc_handle.pid = GET_PID (inferior_ptid);
 
   /* Now attempt to open a connection to the thread library.  */
@@ -705,8 +696,14 @@ thread_db_new_objfile (struct objfile *o
 	       thread_db_err_str (err));
       break;
     }
+}
+
+static void
+thread_db_new_objfile (struct objfile *objfile)
+{
+  if (objfile != NULL)
+    check_for_thread_db ();
 
-quit:
   if (target_new_objfile_chain)
     target_new_objfile_chain (objfile);
 }
Index: src/gdb/Makefile.in
===================================================================
--- src.orig/gdb/Makefile.in	2006-02-27 14:16:21.000000000 -0500
+++ src/gdb/Makefile.in	2006-02-27 14:36:30.000000000 -0500
@@ -2198,7 +2198,7 @@ linux-nat.o: linux-nat.c $(defs_h) $(inf
 linux-thread-db.o: linux-thread-db.c $(defs_h) $(gdb_assert_h) \
 	$(gdb_proc_service_h) $(gdb_thread_db_h) $(bfd_h) $(exceptions_h) \
 	$(gdbthread_h) $(inferior_h) $(symfile_h) $(objfiles_h) $(target_h) \
-	$(regcache_h) $(solib_svr4_h) $(gdbcore_h)
+	$(regcache_h) $(solib_svr4_h) $(gdbcore_h) $(linux_nat_h)
 lynx-nat.o: lynx-nat.c $(defs_h) $(frame_h) $(inferior_h) $(target_h) \
 	$(gdbcore_h) $(regcache_h)
 m2-exp.o: m2-exp.c $(defs_h) $(gdb_string_h) $(expression_h) $(language_h) \
Index: src/gdb/linux-nat.c
===================================================================
--- src.orig/gdb/linux-nat.c	2006-02-27 12:47:52.000000000 -0500
+++ src/gdb/linux-nat.c	2006-02-27 14:36:30.000000000 -0500
@@ -334,12 +334,14 @@ void
 child_post_attach (int pid)
 {
   linux_enable_event_reporting (pid_to_ptid (pid));
+  check_for_thread_db ();
 }
 
 static void
 linux_child_post_startup_inferior (ptid_t ptid)
 {
   linux_enable_event_reporting (ptid);
+  check_for_thread_db ();
 }
 
 int
@@ -963,7 +965,7 @@ lin_lwp_attach_lwp (ptid_t ptid, int ver
       gdb_assert (pid == GET_LWP (ptid)
 		  && WIFSTOPPED (status) && WSTOPSIG (status));
 
-      child_post_attach (pid);
+      target_post_attach (pid);
 
       lp->stopped = 1;
 
Index: src/gdb/linux-nat.h
===================================================================
--- src.orig/gdb/linux-nat.h	2006-02-27 12:56:19.000000000 -0500
+++ src/gdb/linux-nat.h	2006-02-27 14:36:30.000000000 -0500
@@ -65,6 +65,8 @@ struct lwp_info
   struct lwp_info *next;
 };
 
+/* Attempt to initialize libthread_db.  */
+void check_for_thread_db (void);
 
 /* Find process PID's pending signal set from /proc/pid/status.  */
 void linux_proc_pending_signals (int pid, sigset_t *pending, sigset_t *blocked, sigset_t *ignored);

Re: RFC: Initialize libthread_db at the right time

[Michael Snyder]

Daniel Jacobowitz wrote:
> We've had some recurring problems debugging statically linked executables
> using libthread_db; this patch is the first of several fixes for that.
> This doesn't do much; it just splits the check out from the new_objfile
> hook, and calls it from target_post_attach and target_post_startup_inferior
> in the Linux native target.
> 
> Earlier versions of this patch used an observer instead, which was silly
> of me; we only want to do this when we're sitting on top of the Linux
> native target, not when we're on top of e.g. the remote target.  This
> mostly fixes the not-enabling-libthread_db-when-we-should-be class of
> problems; there's still one gross hack in remote.c which avoids
> calling the new objfile hook for remote targets, but that's a mess
> for another day.
> 
> Any comments?  Otherwise, I'll commit this in a few days.  It handles
> LinuxThreads, but NPTL needs a little push (coming up next).

I don't promise that I understand it completely,
but I don't see anything glaringly wrong with it.

Michael

Re: RFC: Initialize libthread_db at the right time

[Daniel Jacobowitz]

On Mon, Feb 27, 2006 at 02:44:14PM -0500, Daniel Jacobowitz wrote:
> We've had some recurring problems debugging statically linked executables
> using libthread_db; this patch is the first of several fixes for that.
> This doesn't do much; it just splits the check out from the new_objfile
> hook, and calls it from target_post_attach and target_post_startup_inferior
> in the Linux native target.
> 
> Earlier versions of this patch used an observer instead, which was silly
> of me; we only want to do this when we're sitting on top of the Linux
> native target, not when we're on top of e.g. the remote target.  This
> mostly fixes the not-enabling-libthread_db-when-we-should-be class of
> problems; there's still one gross hack in remote.c which avoids
> calling the new objfile hook for remote targets, but that's a mess
> for another day.
> 
> Any comments?  Otherwise, I'll commit this in a few days.  It handles
> LinuxThreads, but NPTL needs a little push (coming up next).

OK, more than a few days.  And the NPTL push never got pushed, because
the glibc maintainers didn't like my solution, but have not suggested
an alternative yet.  I'll poke them again.

This part committed.

-- 
Daniel Jacobowitz
CodeSourcery