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

[Andrew Cagney <ac131313@cygnus.com>]

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

Andrew