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

Andrew Cagney
2002-03-16T04:48:10Z

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