Hi Nathan, Do you have some other idea?
"Just add another symbol" is not a good idea. We are going to pass Linux kernel Kconfig is one day or two :-) I think we need to simplify our Kconfig, not to make each more complex every single day. BR, Alan On 11/4/22, Nathan Hartman <hartman.nat...@gmail.com> wrote: > 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 >
