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 >