This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos 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: How to get thread state info?


Grant Edwards <grante@visi.com> writes:

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

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

The code I have is based around some of the same mechanisms.

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

That's fine for just one architecture. It's more complicated if you
need to support it for all of them.

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

That should give you a good approximation of the call stack. But you
will always get false readings if any uninitialized stack locations
happen to contain old return links. The only sure way to get it right
is to work out the stack frames and unwind them properly. That's the
hard part since the compiler's optimizations tend to make them
difficult to detect.

-- 
Nick Garnett - eCos Kernel Architect
http://www.eCosCentric.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


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