Re: [RFA] Don't use thread_db on corefiles

Andrew Cagney
2001-12-15T02:31:18Z

> Oh, is that what you were talking about? Sorry, I must have been
>> confused.
>>
>> So -- you are talking about building a single GDB that can debug
>> 1) native x86 linux, and
>> 2) MIPS multi-threaded linux corefiles.
>>
>> Is that right?
>
>
> Well, that's not actually something I need to do, but I'd like it to be
> possible. I only need for both native and cross-hosted debuggers to
> both be able to get at the core files. But as things stand now, if we
> fix thread_db to be able to do so using lin-lwp, then the native and
> cross debuggers will get at the threads using completely different
> interfaces. That worries me.

At a technical level, it would mean making the thread:lwp mapping
library multi-arch. I think Michael gave a good summary - that isn't a
free lunch. (1)

Returning to the problem at hand though,

If you build --target=mips-unknown-linux-gnu does the resultant GDB
include the native thread-db code? Surely it doesn't since, as you
point out, it can't work. For the moment, would only be able to display
threads, just the raw LWPs.

Hmm, perhaps it is a native GDB looking at a threaded core file? In
that case, yes the thread-db should drop its self on top. If that is
causing an internal error then there is something messed up that should
be fixed.

Andrew

(1) The unixware thread code is a prototype of this sort of thing. I
say prototype since it really needs a proper target stack.