Hi,
I have been testing GCC stack protector on bare metal Cortex-M4 using gcc-arm-none-eabi-9-2020-q2-update and have observed a difference in emitted instructions versus the last GCC 8.x release.
Compiled SSP test code with: -std=gnu11 -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi-hard -ffunction-sections -fdata-sections -fstack-protector-strong --specs=nano.spes --specs=nosys.specs
Map file:
.bss.__stack_chk_guard 0x000000000011ad1c 0x4 /home/void/cc/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libg_nano.a(lib_a-stack_protector.o) 0x000000000011ad1c __stack_chk_guard
object dump (-xDS)
000d9144 <ssp_test1>: d9144: b500 push {lr} d9146: 4b0e ldr r3, [pc, #56] ; (d9180 <ssp_test1+0x3c>) NOTE: R3 = 0x000da9b4 literal pool address d9148: 490e ldr r1, [pc, #56] ; (d9184 <ssp_test1+0x40>) d914a: b093 sub sp, #76 ; 0x4c d914c: 681b ldr r3, [r3, #0] NOTE: R3 = 0x0011ad1c address of __stack_chk_guard d914e: 9311 str r3, [sp, #68] ; 0x44 NOTE: Saves address of __stack_chk_guard, never loads the value! d9150: f04f 0300 mov.w r3, #0 NOTE: clear address of __stack_chk_guard. Is this part of GCC PR85434? d9154: aa01 add r2, sp, #4 d9156: f44f 138c mov.w r3, #1146880 ; 0x118000 d915a: 4618 mov r0, r3 d915c: 3304 adds r3, #4 d915e: 6800 ldr r0, [r0, #0] d9160: f842 0b04 str.w r0, [r2], #4 d9164: 428b cmp r3, r1 d9166: d1f8 bne.n d915a <ssp_test1+0x16> d9168: 4b05 ldr r3, [pc, #20] ; (d9180 <ssp_test1+0x3c>) NOTE: R3 = 0x000da9b4 d916a: 9809 ldr r0, [sp, #36] ; 0x24 d916c: 681a ldr r2, [r3, #0] NOTE: R2 = 0x0011ad1c address of __stack_chk_guard d916e: 9b11 ldr r3, [sp, #68] ; 0x44 NOTE: R3 = address of __stack_chk_guard save in function prolog d9170: 405a eors r2, r3 NOTE: Address match not guard value! d9172: d001 beq.n d9178 <ssp_test1+0x34> d9174: f001 fbc0 bl da8f8 <__stack_chk_fail> d9178: b013 add sp, #76 ; 0x4c d917a: f85d fb04 ldr.w pc, [sp], #4 d917e: bf00 nop d9180: 000da9b4 ; <UNDEFINED> instruction: 0x000da9b4 d9184: 00118040 andseq r8, r1, r0, asr #32
000da9b0 <_global_impure_ptr>: da9b0: 00118208 andseq r8, r1, r8, lsl #4 da9b4: 0011ad1c andseq sl, r1, ip, lsl sp da9b8: 6c707041 ldclvs 0, cr7, [r0], #-260 ; 0xfffffefc
If you think it is a bug, then you should raise an issue in the gcc bugman.
BTW, there is an option to post code nicely.