Hello,
ARM support and R52 TRM have indicated that the R52 core requires maintaining an 8-byte aligned Stack (meaning compiler shall always push/pop registers in even numbers), and I see in my current setup the GNU GCC compiler is not adhering to that requirement. Subsequently in my core simulations I see R52 erroneous behavior if the stack is not maintained as such, especially if only a single register is pushed/popped for a function.
Am I missing some GNU GCC option to force 8-byte stack alignment? Also since ARM support stated this was a necessary requirement, shouldn't that be automatically implemented in the -mtune=cortex-r52 options?
My current setup is using ARM recommended version gcc-arm-none-eabi-9-2020-q2-update (according to the GNU toolchain developer website)
(I have also tested the version gcc-arm-none-eabi-10-2020-q2-preview, still seeing same problems)
My GCC command has the following options:
gcc-arm-none-eabi-10-2020-q2-preview/bin/arm-none-eabi-gcc -march=armv8-r -mfpu=neon-fp-armv8 -mtune=cortex-r52 -marm -c -g -O3 -fno-inline -fno-strict-aliasing -DGCC -falign-functions=16 -falign-jumps=8 -falign-loops=8 -fomit-frame-pointer -funroll-loops -mapcs-frame -DITERATIONS=20 -save-temps -DCR52 -Werror -Wall -Dcr52 -DCORE_0 -std=c99 -o alive_CORE_0.o -c alive.c
From above example, my compile results in the following odd-number of registers pushed onto stack: (see snippet from .lst file)
int main (void) { 2a980: e92dd810 push {r4, fp, ip, lr, pc} <<<=== ODD NUMBER OF REGISTER IN PUSH INSTRUCTION:
NOTE: the problem also occurs if I use -mthumb mode.
Other notes: I added the -fno-inline as according to an internal verification decision that we want to avoid the code in-lining optimization. Additionally I added the -mapcs-frame in an attempt to fix this issue, and this option seems to make the problem a lot better, but doesn't completely fix the problem.
Or is this a GNU GCC bug for the -mtune=cortex-r52 set of tuning options?
Thanks in advance for any help.
Follow-up on original issue:
1) I was in error of misinterpreting the meaning of "ABI compliant stack alignment" requirement to incorrectly infer an 8-byte alignment requirement.
2) the issue I was seeing in simulations tended to manifest itself most frequently where the SP was starting on an odd-word boundary (thus the original focus on the alignment of the stack), these stack transactions to memory resulted in sparse write transactions, and the root of the issue was my slave-memory behavioral model had a bug related to sparse writes that were dropping the write transactions.
Thanks for the clarification in the process that helped educate my misunderstanding.