It is exactly the same issue, I should have checked there, apologies for duplicating. Shall we continue the discussion there?
In any case, I do not think it is such an uncommon scenario... We have hit it in our application (that is why we saw it). I mostly agree with the OP of the original bug report, this is memory space and as such should be allocated somewhere in the memory map instead of assuming there is free space after BSS. I *can* easily produce a patch for armv[678]-m (I have it already implemented as a local patch in my Nuttx copy) and I have updated my linker script (same way as I updated QEMU test one). I can also patch all the obvious ld files for other armv[678]-m targets. But I cannot test those (I do not have the HW) and I might miss some ld file... and the problem is that would render the build unusable (strictly speaking, a linker script change should not be necessary as the stack can be anywhere in the memory, but in other places of ARM-specific code it is assumed stack is contiguous to heap space). Shall I still prepare the patch? (Alan I know you already said but it will take a bit of time to go through all the ld files so I want to confirm before getting to it). BR Carlos On Fri, Nov 4, 2022 at 12:25 PM Fotis Panagiotopoulos <f.j.pa...@gmail.com> wrote: > 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 > > > > > > -- Carlos Sanchez (he, him, his) Geotab Embedded Systems Developer Team Lead | Europe Visit www.geotab.com Twitter <https://twitter.com/geotab> | Facebook <https://www.facebook.com/Geotab> | YouTube <https://www.youtube.com/user/MyGeotab> | LinkedIn <https://www.linkedin.com/company/geotab/>
