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

Andrew Cagney
2002-03-16T02:51:13Z

> --- 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