On Fri, Nov 4, 2022 at 2:12 PM Carlos Sanchez <carlossanc...@geotab.com.invalid> wrote:
> 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). I think this makes sense. Build-time is a much better time to discover that your image won't fit than wondering why the board won't boot and then wasting time with debugging. It is even more important to detect things like this at build time because of automated testing like the pre-checks that run when PRs are opened. Please feel free to ping me when the PR is opened and I'll help review/test it. Cheers Nathan
