As discussed in person with @Xeratec and @Lore0599.
The current linker script used in the 3 targets is borrowed from Cheshire with minimal modifications.
There are several improvement points to address:
- The linker script should exactly reflect what we have in the hardware. This is currently not the case, at least for the
chimera-convolve target, where the private L1 of the host (spm at 0x10000000) is not instantiated in the hardware. I suppose that there are other misalignments needing to be resolved.
.rodata and .data are shoved into one section named .misc. This is bad practice for bare-metal development. .rodata and .data deserve dedicated sections.- There is currently no stack overflow protection in hardware, and the stack pointer can reach the head,
.data, and .text. This is dangerous and leads to "hard-to-debug" bugs. Instead, we should decide (per target, even potentially per application) how much stack we can allocate and initialize the stack pointer at the bottom of the memory. Such that if the stack pointer overflows, the core will try to reach an invalid address. Of course, one has to be careful not to have something addressed in the memory range right before the memory island base. Finally, if some target implements stack overflow protection, then their linker script can have the stack somewhere else.
As discussed in person with @Xeratec and @Lore0599.
The current linker script used in the 3 targets is borrowed from Cheshire with minimal modifications.
There are several improvement points to address:
chimera-convolvetarget, where the private L1 of the host (spmat0x10000000) is not instantiated in the hardware. I suppose that there are other misalignments needing to be resolved..rodataand.dataare shoved into one section named.misc. This is bad practice for bare-metal development..rodataand.datadeserve dedicated sections..data, and.text. This is dangerous and leads to "hard-to-debug" bugs. Instead, we should decide (per target, even potentially per application) how much stack we can allocate and initialize the stack pointer at the bottom of the memory. Such that if the stack pointer overflows, the core will try to reach an invalid address. Of course, one has to be careful not to have something addressed in the memory range right before the memory island base. Finally, if some target implements stack overflow protection, then their linker script can have the stack somewhere else.