Any known compiler issues for CPU32? (stack corruption problem)

[Mike Panetta]

On Wed, 2002-02-27 at 14:35, Eric Norum wrote:
> 
> On Wednesday, February 27, 2002, at 12:51 PM, Mike Panetta wrote:
> 
[snip]
> One can never be 100% sure about this sort of thing, but I can say that 
> I've run scores of applications, some very large (1.2 MBytes of code, 
> 10s of thousands of lines) without difficulty on CPU32 machines using 
> the above toolchain.
> 
> Can you use BDM on the CPU32 to step through the code and narrow down 
> the location where the problem occurs?
> 

Thats what I am doing as we speak.  It seems to go funky somewhere in
fstat(), but I am not 100% sure.  Right now, I am in the middle of
testing a hunch, that I will not have problems if I switched to polled
IO.  Its only a hunch, and it may lead nowhere, but its worth a try :).

As for the stack thing, I am not sure if the SP at the begining of the
task was really corrupt.  I am beginning to think that RTEMS allocates
the tasks stack in the empty space after the main stack, I think its
called the Workspace area?  Either way, something is definately wrong. 
I set a breakpoint at printf, and at SciInterruptWrite, which is
eventually called indirectly from printf after a long way through some
other code.  Everything seemed fine at that breakpoint, I stepped
through it for awhile, and then just decided to continue, the program
locked up.  I waited a few seconds, and then hit the berr switch on the
BDM pod to wake it back up, then displayed the SP, the FP, and the PC. 
The PC was way out in lala land (it was at 0xa3a00680, which is not in
any address space on this board), but the SP and the FP "looked" ok.

Thanks,
Mike "Stumped" Panetta

> Eric Norum                                                  
> eric.norum at usask.ca
> Department of Electrical Engineering       Phone: (306) 966-5394
> University of Saskatchewan                        FAX:   (306) 966-5407
> Saskatoon, Canada.
>