Linker-Script Alignment

[vincenthamp9]

Posted on July 21, 2016 at 11:40

Hello

Has anyone ever noticed that the alignment of certain sections in the linker scripts provided by ST (and Cube) differ between 4 and 8-byte a lot? E.g. The original script for the F407 defines .isr_vector, .text, .data and so on as 4-byte aligned, whereas the script for the L476 defines them all as 8-byte aligned. Is there any specific reason for this? I've always thought 4-byte alignment is sufficient in any case?

[Tesla DeLorean]

Posted on July 21, 2016 at 17:56

ARM's ABI has rules requiring 8-byte alignment of structures/stacks, mainly for things that might contain 64-bit doubles, or ints.

The Cortex-M3/M4 only technically need 4-byte alignment for STRD/LDRD instructions, which would Hard Fault with +1/+2/+3 offsets The Cortex-M0 is more fussy, it can't do unaligned 32-bit load/store. Again 4-byte alignment would suffice, and you only really run into issues with packed structures. Still it catches a lot of people out who haven't used ARM7/ARM9 chips before, and move what they think is valid code on an x86 platform over and it fails. The biggest issue I see with GNU linker scripts is the setting of stupid stack addresses like 0x2001FFFF which cause instant alignment issues, in these cases 0x20020000 would be valid for 128KB RAM systems as SP decrements before the value is written, in this case to 0x2001FFFC

[vincenthamp9]

Posted on July 22, 2016 at 09:11

Thanks for clearing that up.

Have you ever noticed any strange behavior from the GCC compiler when changing the alignment of RAM sections? I've a strange reproducible ''error'' where changing the alignment from a SRAM2 section causes the compiler to optimize initialization values for variables and functions for that section away... So, e.g.

.section .sram
myvar0_sram: .word 3
myvar1_sram: .word 4
myvar2_sram: .word 5

plus an assembler function which loads and stores these values works perfectly fine with an 8-byte aligned RAM, but gets optimized away with a 4-byte aligned one. Any by ''optimized away'' I mean that the initialization values simply don't exist in flash... and neither does the function which should load and store them.