This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: Extra Thread Info
- To: jlarmour at cygnus dot co dot uk
- Subject: Re: Extra Thread Info
- From: Stan Shebs <shebs at cygnus dot com>
- Date: Tue, 30 Nov 1999 13:55:02 -0800
- CC: msalter at cygnus dot com, jtc at redback dot com, gdb at sourceware dot cygnus dot com
Date: Thu, 25 Nov 1999 07:27:38 GMT
From: jlarmour@cygnus.co.uk (Jonathan Larmour)
>Perhaps the eCos developers' judgment is flawed, but they certainly
>preferred adding a packet over the alternative of encoding eCos
>internals into GDB, whether it was as scripts or C code. But this
>decision was made a couple years ago; I'll bring it up with them
>again, perhaps they've changed their minds about this point.
Nope :-). At least not unless the scripts can adapt when the kernel thread
structure can change from program to program. Hard-coded C is right out.
It's feasible to enhance GDB scripting to do this right, but it certainly
isn't possible now. And then there are the other problems like it not
being usable from anything other than the CLUI.
Thanks for the info, I didn't even think about the effect of eCos
configurability.
But it's the performance that's the real killer. Remote debugging over
wet string is slow enough, but add in the latency of script interpretation,
and having to synchronously query each item of thread state with separate
memory reads, and you have an unusable system. eCos is only requesting
the ID, name, and state in addition to the normal info, and the info is
returned in one packet per thread. But it takes around 1 second per thread
with a 38400bps link. It's not nice, but it we really must not do anything
to make it slower, which scripting would do a lot.
I think this is all optimizable - nobody has spent any time on
improvements since the original implementation. We're certainly not
picking up 4K of useful info about each thread...
NB Other OS's may well find it very difficult to export internal structures
without actually having large sections of the OS itself compiled with
debug info, which may well be unacceptable. eCos doesn't mind as we're
open source, but I don't think we should discriminate. The type information
encoded in the debug info is much more interesting than the actual symbols
of course.
While it's a problem, it's not really very serious, because you can
pick up the info just by including some sort of <thread_struct.h> in
your app somewhere. Often you have to do that anyway just to use
threads in the first place. Still, enough users will forget this, or
experience the linker doing symbol GC, or whatever, so it will make
scripts seem unreliable.
I think what is required is to draw up a list of all the thread concepts
we already know that users would want to know about: thread ID, name,
priority, state, stack frame at least. A target stub may support any or
all of these.
The name makes sense as a general concept - Tom Tromey points out that
it's useful for Java too - and stack frame is implicit in the thread's
register set. Priority and state are rather variable in nature, which
I would prefer to have them be glommed into a single string. As a
corollary, I'm not too keen on building in an elaborate bitmap
mechanism, but there are other ways to reduce bandwidth, I'll think
about the issue a bit more.
Stan