This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bus Fault


On 03/17/2016 03:40 AM, spflanze wrote:
> This is a firmware project of mine. The IDE is the Ac6 System Workbench.
> The target processor is an STM32F373VCT6.
> 
> I find that whenever I have a function that has within it a call to another
> function this instruction sequence appears among the first instructions in
> the function that does the call.
> 
> sub.w r3, sp, #12224    ; 0x2fc0
> subs r3, #60    ; 0x3c
> movs r2, #0
> str r2, [r3, #0]
> 
> This sequence results in a Bus Fault because in the last instruction r3
> points to a location in flash memory instead of a location in RAM as it
> should. The details of how that happens is posted in this thread of mine
> that I began when I thought this was a FREERTOS problem:
> https://sourceforge.net/p/freertos/discussion/382005/thread/da34d0b6/
> 
> This instruction sequence is not just near the start thread function for
> which I posted source code. It is near the start of every start thread
> function in the project. If there are no function calls withing the start
> thread function the above instructions disappear.
> 
> Why do these functions need to store a value of 0 at a location so far from
> the current stack pointer address? What is this instruction sequence
> supposed to accomplish?

It would have been nice, if you would have included the gcc command line.

Do not use -fstack-check. It's the cause of your problems. The compiler
obviously assumes that you need at least 12224 bytes of stack
(seems to come from gcc/defaults.h, STACK_CHECK_PROTECT). The code tries
to touch deep into the stack in order to fault in case of a too small
stack (and faulting is what it does, doesn't it? :-) ).

If you need stack checking, setup a 32 byte guard band (must by 32-byte
aligned) at the bottom of your stack, protect it with the mpu of the
cortex-m4 and switch the region register on every context switch.
That way you need only one MPU region.

Setup another region register to cover the bottom of your interrupt stack.

And now that you have started using the mpu make use of the remaining
regions (you have 8).

e.g.:
Region 0: Disallow any access to the first gigabyte (catches
NULL-pointer access),
Region 1/2: Allow access only to the ram you actually have (no access to
mirrored locations)
Region 3: Disallow writes to your flash, allow read access only to the
amount of flash you actually have (no access to mirrored locations)
Region 4: Disallow write access to your vector table. That way your
fault handlers can't get compromised.
Region 5: Interrupt stack guard band
Region 6: Task stack guard band
Region 7: Spare

That's not perfect, but it will catch most stack overflows and lots of
illegal pointer usages.

regards, Matthias
-- 
Matthias Pfaller                          Software Entwicklung
marco Systemanalyse und Entwicklung GmbH  Tel   +49 8131 5161 41
Hans-Böckler-Str. 2, D 85221 Dachau       Fax   +49 8131 5161 66
http://www.marco.de/                      Email leo@marco.de
Geschäftsführer Martin Reuter             HRB 171775 Amtsgericht München


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]