On Fri, Nov 4, 2022 at 4:06 PM Nathan Hartman <hartman.nat...@gmail.com> wrote:
> 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. > I just had a thought. The linker scripts really should be per-arch, not per-board, right? Then again, a particular board might have a special requirement that needs a custom linker script just for that board. So maybe it would make more sense to migrate all the linker scripts to be per-arch and add a Kconfig, e.g., a bool CONFIG_BOARD_LINKER_SCRIPT. If true, then the board needs to provide its own ld.script; if false, we use the default per-arch ld.script, and for most boards that should be adequate. If this is done, then fixes like Carlos is discussing would take much less work. Thoughts? Cheers Nathan
