Yes, so seems like a Kconfig issue that we didn't pay attention to. On Wed, May 6, 2026 at 11:45 AM raiden00pl <[email protected]> wrote:
> the problem lies here: > > choice > prompt "Optimization Level" > default DEBUG_NOOPT if DEBUG_SYMBOLS > default DEBUG_FULLOPT if !DEBUG_SYMBOLS > > but DEBUG_NOOPT is not required for DEBUG_SYMBOLS. > Debugging experience is also good with -O1 or -O2 > > śr., 6 maj 2026 o 16:39 raiden00pl <[email protected]> napisał(a): > > > weact-stm32h750:nsh from 3c9a9d683f2291ce88af2fa04382fe15a8b37932 > > commit uses CONFIG_DEBUG_NOOPT=y. No wonder it doesn't fit on 128KB > Flash. > > There is nothing strange here. > > > > śr., 6 maj 2026 o 16:28 Alan C. Assis <[email protected]> napisał(a): > > > >> Hi Peter, > >> > >> It is not only in CI, if I roll back the git to some commit before my > >> commit that disabled the debug symbols the issue appears: > >> > >> $ git reset --hard 3c9a9d683f2291ce88af2fa04382fe15a8b37932 > >> > >> $ ./tools/configure.sh weact-stm32h750:nsh > >> > >> $ make -j > >> > >> LD: nuttx > >> arm-none-eabi-ld: /home/alan/nuttxspace/nuttx/nuttx section `.text' will > >> not fit in region `flash' > >> arm-none-eabi-ld: region `flash' overflowed by 1668 bytes > >> Memory region Used Size Region Size %age Used > >> itcm: 0 B 64 KB 0.00% > >> flash: 132740 B 128 KB 101.27% > >> dtcm1: 0 B 64 KB 0.00% > >> dtcm2: 0 B 64 KB 0.00% > >> sram: 6416 B 512 KB 1.22% > >> sram1: 0 B 128 KB 0.00% > >> sram2: 0 B 128 KB 0.00% > >> sram3: 0 B 32 KB 0.00% > >> sram4: 0 B 64 KB 0.00% > >> bbram: 0 B 4 KB 0.00% > >> make[1]: *** [Makefile:226: nuttx] Error 1 > >> make: *** [tools/Unix.mk:568: nuttx] Error 2 > >> > >> So, it is not just a glitch in the CI, the issue also happened building > it > >> locally. > >> > >> BR, > >> > >> Alan > >> > >> On Wed, May 6, 2026 at 11:09 AM Peter Barada <[email protected]> > >> wrote: > >> > >> > Alan, > >> > > >> > Any chance a CI build tree that fails could be squirreled away > >> > short-term so if interested one could inspect it? In this case being > >> > able to inspect the build tree that failed would be most useful as > >> > opposed to waiting for the failure to happen again. > >> > > >> > By default I can see disabling ERR/WARN/INFO and DEBUG_FEATURES in > >> > resource constrained configurations, but not globally to make sure a > PR > >> > doesn't quietly cause a failure that's only visible if DEBUG_FEATURES > >> > and ERR/WARN/INFO are enabled. I'd suggest (if possible) to have a CI > >> > build configuration for each arch/family that tries to turn everything > >> > on to make sure there are no lurking issues. > >> > > >> > On 5/6/26 09:49, Alan C. Assis wrote: > >> > > Ok, I just tested again enabling: > >> > > > >> > > CONFIG_DEBUG_SYMBOLS=y > >> > > CONFIG_DEBUG_SYMBOLS_LEVEL="-g" > >> > > > >> > > And the size didn't change. I think we need to investigate this > >> > > "intermittent" issue that happened in the mainline. > >> > > > >> > > But about CONFIG_DEBUG_FEATURES=y and its ERR/WARN/INFO, they will > >> > increase > >> > > the firmware size, I think those we can remove. > >> > > > >> > > BR, > >> > > > >> > > Alan > >> > > > >> > > On Wed, May 6, 2026 at 10:39 AM raiden00pl <[email protected]> > >> wrote: > >> > > > >> > >> -1. > >> > >> > >> > >> This project is for devs, the main tool used by dev is the debugger > >> and > >> > >> disabling debug symbols only breaks the workflow for users and > makes > >> > life > >> > >> harder. > >> > >> Debug symbols have no effect on resource usage unless you're > loading > >> > >> ELF directly on target (kernel mode, modules) or something is > broken > >> in > >> > the > >> > >> build > >> > >> system or linker. Debug symbols are DWARF information that get > >> embedded > >> > >> into > >> > >> the ELF not binary. > >> > >> > >> > >> śr., 6 maj 2026 o 15:31 Matteo Golin <[email protected]> > >> > napisał(a): > >> > >> > >> > >>> Good idea! In the meantime we can just grep for these options and > >> > remove > >> > >>> them. > >> > >>> > >> > >>> On Wed, May 6, 2026, 3:27 PM Alan C. Assis <[email protected]> > >> wrote: > >> > >>> > >> > >>>> Hi Everyone, > >> > >>>> > >> > >>>> Recently we faced an issue that was breaking the CI: the > >> > >>>> weact-stm32h750:nsh was exhausting its Flash memory. And it is > very > >> > >>> strange > >> > >>>> since this STM32H750 chip has 128KB Flash. > >> > >>>> > >> > >>>> My first thought was that some very heavy feature was enabled to > >> nsh > >> > >> (by > >> > >>>> default nsh is supposed to be bare minimum). Then after analysing > >> the > >> > >>>> .config I noticed that CONFIG_DEBUG_SYMBOLS=y was enabled. > >> > >>>> > >> > >>>> After disabling it, the Flash usage dropped to 55%. I didn't > >> > >> investigate > >> > >>>> yet what caused the memory use increase in the last few days. > >> > >>>> > >> > >>>> I think we should accept Michael's offer to use his membrowser to > >> see > >> > >>> these > >> > >>>> usage increases before the issue triggers the limit. I asked if > he > >> > >> could > >> > >>>> release it as a dual license (GPLv3 and Apache) to avoid the > >> concerns > >> > >>>> raised on this PR, but didn't receive a response yet. > >> > >>>> > >> > >>>> In the past Greg never allowed DEBUG symbols and features to be > >> > enabled > >> > >>> by > >> > >>>> default. I think we should keep this same rule because sooner or > >> later > >> > >>>> other boards will fail in the same way. > >> > >>>> > >> > >>>> BR, > >> > >>>> > >> > >>>> Alan > >> > >>>> > >> > > >> > > >
