Re: [hjl@lucon.org: Re: Does gdb 5.2 work with statically linked thread application under Linux?]

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Mar 15, 2002 at 09:51:06PM -0500, Andrew Cagney wrote:
> >--- 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/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)
> > }
> 
> 
> The below just feels wrong.  The hook is pulling the thread stratum off 
> the stack when, as far as I can tell, there is no compelling reason for 
> doing this.
> 
> ``hey'' something has happened.  At this point, nothing has happened.

What do you mean by "there is no compelling reason"?  Or how should
this be handled?  The issue is that we do not want thread_db to be used
at all for corefiles; we established that last time I touched this
code, I just solved the problem wrong.  Once again, it doesn't work
as-is, and unpushing matches the way the code was trying to behave.

> > 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;
> >+}
> 
> It is possible to have thread, process and core-file stratum 
> simultaneously.  Changing the core-file shouldn't quietly zap the thread 
> stratum on top of the process stratum.
> 
> I suspect the real problem here is a limitation in the current target 
> frame work - it doesn't accomodate having two instances of the thread 
> stratum active (one for the process and one for the core file) active at 
> the same time :-(

The target stack is almost entirely undocumented, unfortunately.  But
from this it seems that changing targets should change the stack
completely; be it a multi-arch thing or a local/remote thing (we've
seen thread_db do the same thing in that case) or a local/core thing.

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