I think this issue is related?
https://github.com/apache/incubator-nuttx/issues/2001
On Thu, Nov 3, 2022 at 9:12 PM Alan C. Assis <acas...@gmail.com> wrote:
> 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
> >
>
