Re: Extra Thread Info

[Stan Shebs <shebs at 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