This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]