Hi Carlos,
I tested and confirmed the issue:
$ patch -p1 <
~/Desktop/0001-Changes-to-force-fill-bss-section-causing-sp-past-th.patch
patching file arch/arm/src/armv7-m/arm_vectors.c
$ ./tools/configure.sh lm3s6965-ek:qemu-flat
$ make -j8
$ qemu-system-arm -semihosting \
-M lm3s6965evb \
-device loader,file=nuttx.bin,addr=0x00000000 \
-netdev user,id=user0 \
-nic user,id=user0 \
-serial mon:stdio -nographic
$ qemu-system-arm -semihosting -M lm3s6965evb -device
loader,file=nuttx.bin,addr=0x00000000 -netdev user,id=user0 -nic
user,id=user0 -serial mon:stdio -nographic
qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
R00=00000000 R01=00000000 R02=40025000 R03=00000004
R04=00000000 R05=2000c620 R06=00000003 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=200101e8 R14=00000b7b R15=00000000
XPSR=00000003 ---- A handler
FPSCR: 00000000
Aborted (core dumped)
Please submit the PR and includer for v6/8 too.
BR,
Alan
On 11/3/22, Carlos Sanchez <carlossanc...@geotab.com.invalid> wrote:
> Hi all,
>
> I have detected the armv{6,7,8}-m/arm_vectors.c assigns the initial
> stack pointer value (using the first entry at the exception vectors
> table) just to _ebss + CONFIG_IDLETHREAD_STACKSIZE, without further
> checking. This can yield to an unusable binary if .data or .bss
> sections grow too much.
>
> To test, use the attached patch 0001 and ./tools/configure.sh
> lm3s6965-ek:qemu-flat
>
> (Note with stacks just below SRAM limit the NSH prompt will still not
> be visible because booting will fail during heap allocation, but still
> the "ABCDF" booting markers will be shown; when the stack starting
> point is past the SRAM end, booting fails immediately and those
> markers are not shown).
>
> There are multiple ways to fix (= detect this at build time) this
> problem. The best IMHO is to make the stack space appear at the memory
> map and be allocated. This will cause a region overflow error during
> linking when the initial stack overflows SRAM (as intended). For a
> demo of this fix (for lm3s6965-ek:qemu-flat only) see attached patch
> 0002.
>
> Unfortunately, this requires linker script changes for most platforms.
> Without the changes, the initial stack would be correctly allocated
> (ld would just map ".stack" section to any writable memory region) but
> several other parts of the code assume the heap to be just after the
> idle thread stack, which cannot be guaranteed without the
> aforementioned linker script changes.
>
> So I want to ask here for opinion before progressing further, as a
> change this deep would affect a lot of platforms which I do not have
> the means to test.
>
> WDYT?
>
> Carlos
>
