Re: [ECOS] How to get thread state info?

[Grant Edwards <grante at visi dot com>]

On Mon, Dec 09, 2002 at 07:07:12PM +0000, Nick Garnett wrote:

> > For troubleshooting purposes, I would like to be abled to
> > display the states of all the threads in the system (SP, IP,
> > thread state, backtrace).  Are there any existing methods to do
> > something like that?
> 
> Well, GDB will do it.
> 
> But I assume that you want to do it from within eCos.

Yup.  We've got a stack of 16 boxes, and once every few days
one of them will stop responding to normal stimuli even though
at least one of the threads (which does very little) is still
running.

> In which case, at the present the answer is no. However, I do
> have some code I have been working on myself that does most of
> what you are after: enumerating all the threads and getting
> some info from them (state, priority, stack base and size
> etc.).

I've got something mostly working based on code from
dbg_gdb.cxx.  It's ARM specific, but it's a temporary hack [I
hope].

> Some of the things you want are not very easy. SP and IP are
> architecture specific. We would have to add new macros to every
> HAL to extract them from saved thread states.

I just grab the HAL_SavedRegisters struct from the thread and
display its contents from my application code.

> Backtrace is really hard, GDB contains all sorts of dodgy
> heuristics to try and get this right. We couldn't possibly
> duplicate that on the target.

When I dump each thread's stack, I check values against various
linker section begin/end and print a "hint" if it matches. It's
a bit iffy and produces false positives since a lot of typical
integer values (0-4K) could also be pointers into the text
section which starts at 384.  If the text section was at the
top end of memory, it would works better, since really large
integers are far more rare.  I'm thinking about temporarily
moving my text section up a ways to a region where things like
buffer and string length parameters can't be confused with
return address pointers.

> I'll see if I can check the code I have into the repository.

-- 
Grant Edwards
grante@visi.com

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss