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

Mike Panetta ahuitzot at
Wed Feb 27 18:51:49 UTC 2002

Are there any known compiler issues when generating CPU32 code with the
rtems binutils-2.11.2-1 or the rtems gcc2.95.3newlib1.9.0-3?  I am
getting stack corruption on one machine, that I am not on another, both
m68k, but one is 68030 and the other is 68332 based.  I do not think the
corruption is occuring in BSP specific code, and since the RTEMS main
code works on one machine and not the other, I am beginning to suspect
the compiler.  So if anyone has had problems with the above compiler on
a CPU32 based machine, or just know (because they are intimate with the
compiler) that there are bugs with it for CPU32, please tell me :)  If
anyone has an idea on how I could track down this stack corruption
problem, I would love that kind of info too :)  

So far, all I know, is somewhere before the code gets to Init() (in
hello sample) the stack gets messed so bad that the stack pointer is
pointing to an address over 5000 bytes above the top of the stack!  In
addition the frame pointer has been set to 0 (is that ok?). Its fine at
boot_card(), and its fine at console_initialize() (a bsp specific
routine in this case), but between console_initialize() and Init() it
goes south.  I have stepped through all the code in console_initialize,
and the stack seems fine in there too. Maybe this is just me not quite
understanding how RTEMS initializes the stack for a process...  I do
know, that if I let the program run without any breakpoints, it goes
wild and overwrites itself...  Isn't that generally an indication of
stack corruption?


More information about the users mailing list