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

[Andrew Cagney <ac131313@cygnus.com>]

>> If you don't want thread-db trying to push its self on top of a core 
>> stratum, why not check for core and ignore the event?

What about this?

>> (GNU/Linux doesn't want the thread-db pushing its self on top of a CORE 
>> stratum but other OS's do (with an N:M thread:lwp mapping for instance).
> 
> 
> I can't find the precise message any more, but I believe we'd decided
> thread-db and core files was a bad idea without more work on thread-db. 
> In any case, Michael Snyder said to me:

It isn't thread-db that needs the work, it is the target 
stack/stratum/sandwich :-)

>>>> Umm... I had to think about this, but no.  You can't debug a corefile
>>>> until you kill or detach from the process that you're already
>>>> debugging.
>>>> When you kill or detach, that ought to take care of the unpush.

Two reasons:

Target stratum (thread, process, ...) is limited to only one instance as 
most of each target's state is in static data

The target stratum is one dimentional (for want of a better phrase).  It 
isn't possible to have:

	process:  thread-db -> remote -> ...
	core: thread-db -> corefile -> ...

> Maybe it should, but (probably because of when thread-db gets pushed?)
> it definitely does not.  Perhaps that is the real bug?
> 
> Should thread_db_detach call unpush_target?  Some targets seem to like
> that model, some don't.  The way we load our target in new_objfile_hook
> always struck me as somewhat gross.

I suspect, for the moment, it is the best thing we have. 
new_objfile_hook is the only ``new symbol file'' event available.

Andrew