Does gdb 5.2 work with statically linked thread application under Linux?

Does gdb 5.2 work with statically linked thread application under Linux?

[H . J . Lu]

Does gdb 5.2 work with statically linked thread application under
Linux? It doesn't work for me at all. It doesn't know any thread.
I have a patch which works for gdb 5.1. Now it doesn't work for 5.2
anymore.


H.J.

Re: Does gdb 5.2 work with statically linked thread application under Linux?

[Daniel Jacobowitz]

On Wed, Mar 06, 2002 at 11:30:50PM -0800, H . J . Lu wrote:
> Does gdb 5.2 work with statically linked thread application under
> Linux? It doesn't work for me at all. It doesn't know any thread.
> I have a patch which works for gdb 5.1. Now it doesn't work for 5.2
> anymore.

My fault, I think.

The problem is that in a dynamically linked binary
thread_db_new_objfile will be called for every library is loaded.  At
this point current_target is "child", so target_has_execution is true.
But with a static binary, the first time the function is called objfile
is NULL, and the second time current_target is "exec" (which has
target_has_execution set false).

Perhaps target_has_execution was not the right check after all, if
"exec" has it set false (which makes fairly little sense to me...) or
perhaps we need to call the hook again later.  Michael, any idea?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Does gdb 5.2 work with statically linked thread application under Linux?

[H . J . Lu]

On Thu, Mar 07, 2002 at 02:48:41AM -0500, Daniel Jacobowitz wrote:
> On Wed, Mar 06, 2002 at 11:30:50PM -0800, H . J . Lu wrote:
> > Does gdb 5.2 work with statically linked thread application under
> > Linux? It doesn't work for me at all. It doesn't know any thread.
> > I have a patch which works for gdb 5.1. Now it doesn't work for 5.2
> > anymore.
> 
> My fault, I think.
> 
> The problem is that in a dynamically linked binary
> thread_db_new_objfile will be called for every library is loaded.  At
> this point current_target is "child", so target_has_execution is true.
> But with a static binary, the first time the function is called objfile
> is NULL, and the second time current_target is "exec" (which has
> target_has_execution set false).
> 
> Perhaps target_has_execution was not the right check after all, if
> "exec" has it set false (which makes fairly little sense to me...) or
> perhaps we need to call the hook again later.  Michael, any idea?
> 

What is the problem if "|| !target_has_execution" is removed? I removed
it. Gdb now works on statically linked thread application as well as
core file. Did I miss soemthing?


H.J.

Re: Does gdb 5.2 work with statically linked thread application under Linux?

[Daniel Jacobowitz]

On Thu, Mar 07, 2002 at 01:39:28PM -0800, H . J . Lu wrote:
> On Thu, Mar 07, 2002 at 02:48:41AM -0500, Daniel Jacobowitz wrote:
> > On Wed, Mar 06, 2002 at 11:30:50PM -0800, H . J . Lu wrote:
> > > Does gdb 5.2 work with statically linked thread application under
> > > Linux? It doesn't work for me at all. It doesn't know any thread.
> > > I have a patch which works for gdb 5.1. Now it doesn't work for 5.2
> > > anymore.
> > 
> > My fault, I think.
> > 
> > The problem is that in a dynamically linked binary
> > thread_db_new_objfile will be called for every library is loaded.  At
> > this point current_target is "child", so target_has_execution is true.
> > But with a static binary, the first time the function is called objfile
> > is NULL, and the second time current_target is "exec" (which has
> > target_has_execution set false).
> > 
> > Perhaps target_has_execution was not the right check after all, if
> > "exec" has it set false (which makes fairly little sense to me...) or
> > perhaps we need to call the hook again later.  Michael, any idea?
> > 
> 
> What is the problem if "|| !target_has_execution" is removed? I removed
> it. Gdb now works on statically linked thread application as well as
> core file. Did I miss soemthing?

Try running 'info threads' on the corefile of a multithreaded
application.  Recent Linux kernels will allow them to dump core.

I've also got a patch to put multiple threads into the corefile. 
There's a sample corefile at:
  http://crack.them.org/~drow/mtc2.tar.gz


Without !target_has_execution, we try to use lin-lwp on the coredump. 
That works very badly.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Does gdb 5.2 work with statically linked thread application under Linux?

[H . J . Lu]

On Thu, Mar 07, 2002 at 05:02:07PM -0500, Daniel Jacobowitz wrote:
> On Thu, Mar 07, 2002 at 01:39:28PM -0800, H . J . Lu wrote:
> > On Thu, Mar 07, 2002 at 02:48:41AM -0500, Daniel Jacobowitz wrote:
> > > On Wed, Mar 06, 2002 at 11:30:50PM -0800, H . J . Lu wrote:
> > > > Does gdb 5.2 work with statically linked thread application under
> > > > Linux? It doesn't work for me at all. It doesn't know any thread.
> > > > I have a patch which works for gdb 5.1. Now it doesn't work for 5.2
> > > > anymore.
> > > 
> > > My fault, I think.
> > > 
> > > The problem is that in a dynamically linked binary
> > > thread_db_new_objfile will be called for every library is loaded.  At
> > > this point current_target is "child", so target_has_execution is true.
> > > But with a static binary, the first time the function is called objfile
> > > is NULL, and the second time current_target is "exec" (which has
> > > target_has_execution set false).
> > > 
> > > Perhaps target_has_execution was not the right check after all, if
> > > "exec" has it set false (which makes fairly little sense to me...) or
> > > perhaps we need to call the hook again later.  Michael, any idea?
> > > 
> > 
> > What is the problem if "|| !target_has_execution" is removed? I removed
> > it. Gdb now works on statically linked thread application as well as
> > core file. Did I miss soemthing?
> 
> Try running 'info threads' on the corefile of a multithreaded
> application.  Recent Linux kernels will allow them to dump core.
> 
> I've also got a patch to put multiple threads into the corefile. 
> There's a sample corefile at:
>   http://crack.them.org/~drow/mtc2.tar.gz
> 
> 
> Without !target_has_execution, we try to use lin-lwp on the coredump. 
> That works very badly.
> 

This patch works for me.


H.J.
----
2002-03-07  H.J. Lu  (hjl@gnu.org)

	* target.h (target_corefile_hook): New prototype.

	* target.c (target_corefile_hook): New.

	* corelow.c (core_open): Call target_corefile_hook if needed.

	* thread-db.c (thread_db_corefile): New.
	(thread_db_new_objfile): Don't check target_has_execution.
	(_initialize_thread_db): Set target_corefile_hook to
	thread_db_corefile.

--- gdb/corelow.c.static	Wed Mar  6 22:30:49 2002
+++ gdb/corelow.c	Thu Mar  7 15:01:41 2002
@@ -303,6 +303,9 @@ core_open (char *filename, int from_tty)
 	     filename, bfd_errmsg (bfd_get_error ()));
     }
 
+  if (target_corefile_hook)
+    target_corefile_hook ();
+
   /* Looks semi-reasonable.  Toss the old core file and work on the new.  */
 
   discard_cleanups (old_chain);	/* Don't free filename any more */
--- gdb/target.c.static	Wed Mar  6 22:31:31 2002
+++ gdb/target.c	Thu Mar  7 14:54:50 2002
@@ -38,6 +38,8 @@
 
 extern int errno;
 
+void (*target_corefile_hook) (void);
+
 static void target_info (char *, int);
 
 static void cleanup_target (struct target_ops *);
--- gdb/target.h.static	Wed Mar  6 22:31:31 2002
+++ gdb/target.h	Thu Mar  7 14:54:38 2002
@@ -985,6 +985,8 @@ extern char *normal_pid_to_str (ptid_t p
 
 extern void (*target_new_objfile_hook) (struct objfile *);
 
+extern void (*target_corefile_hook) (void);
+
 #ifndef target_pid_or_tid_to_str
 #define target_pid_or_tid_to_str(ID) \
      target_pid_to_str (ID)
--- gdb/thread-db.c.static	Wed Mar  6 22:31:31 2002
+++ gdb/thread-db.c	Thu Mar  7 14:59:09 2002
@@ -479,13 +479,25 @@ disable_thread_signals (void)
 }
 
 static void
+thread_db_corefile (void)
+{
+  if (using_thread_db)
+    {
+      /* If the thread_db target is active, deactivate it now.  */
+      gdb_assert (proc_handle.pid == 0);
+      unpush_target (&thread_db_ops);
+      using_thread_db = 0;
+    }
+
+  keep_thread_db = 0;
+}
+
+static void
 thread_db_new_objfile (struct objfile *objfile)
 {
   td_err_e err;
 
-  /* Don't attempt to use thread_db on targets which can not run
-     (core files).  */
-  if (objfile == NULL || !target_has_execution)
+  if (objfile == NULL)
     {
       /* All symbols have been discarded.  If the thread_db target is
          active, deactivate it now.  */
@@ -1040,5 +1052,6 @@ _initialize_thread_db (void)
       /* Add ourselves to objfile event chain.  */
       target_new_objfile_chain = target_new_objfile_hook;
       target_new_objfile_hook = thread_db_new_objfile;
+      target_corefile_hook = thread_db_corefile;
     }
 }