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

[Joel Sherrill]

Chris Johns wrote:
> 
> Mike Panetta wrote:
> 
> >
> > 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.
> >
> 
> Do you have the correct libgcc.a being linked ? This is the typical
> printf problem on the m68k given the stack is large enough. Try:
> 
>    $ m68k-elf-objdump -D your.elf | grep fsave

Is there any chance you have taken a interrupt before there
are vectors?  Do you accidentally have interrupts enabled? 

> --
>   Chris Johns, cjohns at cybertec.com.au

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985