Re: [ECOS] SIGTRAP question

[Jonathan Larmour <jlarmour at redhat dot co dot uk>]

Nicole Cook wrote:
> 
> Jonathan Larmour wrote:
> >
> > With some targets/MMUs, if you try to jump to wacky addresses it will cause
> > it to reset. I don't know off-hand if the AEB C is in this category, but
> > they may well be the "cause". Of course the real question is why such a
> > wacky address is trying to get loaded in the first.
> >
> This seems to be what's happening, though I don't know why - it tries
> to load an address that corresponds to a huge list of nops in
> cyg_libc_main_stack, but instead resets (it is reproduceable - it
> happens every time).

The next thing to do is to try and determine where this corruption takes
place. Stop at the entry point of the function, and check the return pc is
stored correctly. Keep stepping until you find out what is wrong (assuming
the function isn't too large :-/ ). In particular, check the frame pointer
is the correct value when the function exits, as what it was after the
prologue on function entry.

Also when you find out what memory address $pc is stored at, use "display"
to show that memory directly, so as you step through, you can see if it
changes.

Which tools are you using BTW? Did you try compiling without optimization?

If it isn't a tools problem, the highest possibility on the list is
probably some stack corruption in your code, e.g. writing beyond the bounds
of an array allocated on the stack. Perhaps try the standard debugging
approach of commenting out bits of code to see which bit causes the problem
to go away.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault