AnsweredAssumed Answered

Corrupted main() stack with v5 Blackfin C compiler.

Question asked by DonMilne on Sep 12, 2011
Latest reply on Oct 3, 2013 by DonMilne

This is not a toolchain bug, just another "gotcha" that can lead to a nasty, hard to pin down, stack corruption bug: hence I thought I would alert people about it.

 

I have a Blackfin C+asm project first started in v3 days. I found that if I built this project with v5 then it locked up during reset, except not always!  My project has some complex code, but it didn't even seem to be reaching that. The symptoms appeared random. Bug in an interrupt handler? Nightmare!

 

After a fierce struggle I eventually pinned it down: the main() function written in C was allocating x bytes of local stack space, but was storing some locals at addresses >x !  I thought I'd found a compiler bug, but then I remembered: if you call a C function from assembler then you are supposed to allocate 12 bytes of stack space for arguments even if the called function doesn't need it. There is a brief paragraph in the latest manuals saying that the v5 C compiler now uses this stack space for locals. I knew all this, but didn't think it applied to me because I wasn't calling into C from "my" assembler modules...

 

...except that I'd forgotten my startup.asm module, which boots up the processor and ends with a jump to my C main() routine.  As far as the C compiler is concerned, main() is just another function and it expects those 12 stack bytes to have been allocated prior to the jump. If the space was not allocated then you get stack corruption. My startup.asm was based on an ADI template that existed in v3, and which didn't allocate that stack space. I had barely looked at this module since I first got it working.

 

You may want to check this in your own pre-v5 Blackfin C projects.

Outcomes