BSS section size issue (arm family shared linker script)

General
1

Hi! I’m encountering an issue with my minimal RTEMS application using the official STM32F4 BSP, where the .bss section scales to nearly fill the entire RAM size defined in the linker script, regardless of the actual memory needs. The project contains only init.c with no large arrays, and all unnecessary drivers and components are disabled (e.g., console, filesystem). The linker script is based on linkcmds.armv7m, with a custom memory definition. Below are three configurations with different RAM sizes and their size outputs, showing .bss consistently occupying almost all available RAM.

Linker Script Configurations:

  1. RAM = 384 KB:

    MEMORY {
    RAM_INT : ORIGIN = 0x20000000, LENGTH = 384K
    ROM_INT : ORIGIN = 0x08000000, LENGTH = 1M
}
. . .
. . . 
INCLUDE linkcmds.armv7m

    Size Output:

       text    data     bss     dec     hex filename
  70864    1244  392004  464112   714f0 app.elf
    • .bss = ~383 KB (almost entire RAM).

  2. RAM = 128 KB:

    MEMORY {
    RAM_INT : ORIGIN = 0x20000000, LENGTH = 128K
    ROM_INT : ORIGIN = 0x08000000, LENGTH = 1M
}
. . .
. . . 
INCLUDE linkcmds.armv7m

    Size Output:

       text    data     bss     dec     hex filename
  70796    1244  129860  201900   314ac app.elf
    • .bss = ~126.8 KB (almost entire RAM).

  3. RAM = 5000 KB:

    MEMORY {
    RAM_INT : ORIGIN = 0x20000000, LENGTH = 5000K
    ROM_INT : ORIGIN = 0x08000000, LENGTH = 1M
}
. . .
. . . 
INCLUDE linkcmds.armv7m

    Size Output:

       text    data     bss     dec     hex filename
  47776     856 5119172 5167804  4edabc app.elf
    • .bss = ~5000 KB (almost entire RAM).

Questions:

  1. Why does .bss scale to match the RAM_INT size, and how can I prevent this to ensure .bss only includes actual variables?
  2. How does the stack behave in this scenario? Specifically, with .bss consuming almost all RAM_INT, is the stack (defined in .stack with bsp_stack_main_size = 4096) properly allocated, or is it being overwritten or truncated? How can I verify stack integrity?
  3. Are there known issues with the STM32F4 BSP or linkcmds.armv7m that could cause this behavior?

Any insights or suggestions on debugging this issue and ensuring proper stack allocation would be greatly appreciated!

UPD:

The arm-rtems7-size command in Berkeley format (text, data, bss) incorrectly aggregates all NOBITS sections in RAM_INT (.bss, .rtemsstack, .noinit, .work) into the reported .bss size. The .work section, which reserves nearly all remaining RAM_INT space (e.g., 5105472 bytes for 5000K), dominates this aggregated size.

arm-rtems7-size --format=SysV app.elf
app.elf  :
section                 size        addr
.start                   784   134217728
.xbarrier                  0   536870912
.text                  39756   134218560
.init                     12   134258316
.fini                     12   134258328
.robarrier                 0   134258340
.rodata                 7088   134258344
.ARM.exidx                 8   134265432
.eh_frame                  4   134265440
.tbss                     24   134265444
.init_array                4   134265444
.fini_array                4   134265448
.rtemsroset              112   134265452
.rwbarrier                 0   536870912
.vector                  524   536870912
.data                    848   536871440
.bss                    5408   536872288
.rtemsstack             4096   536877696
.noinit                 3648   536881792
.work                5105472   536885440
.stack                     0   541990912
.nocachenoload             0   541990912
.comment                 108           0
.debug_aranges         11120           0
.debug_info           942888           0
.debug_abbrev         136143           0
.debug_line           264976           0
.debug_frame           21932           0
.debug_str             84276           0
.debug_line_str          442           0
.debug_loclists       172861           0
.debug_rnglists        22774           0
.ARM.attributes           48           0
.debug_gdb_scripts       135           0
Total                6825507
2

Solution for Displaying Executable File Section Sizes

I have partially resolved the issue with outputting information about an executable file. Here is the code, if anyone is interested. Add this code to your custom WAF script:

import subprocess

def size_sysv_print(ctx):
    """Print sizes of executable using SysV format"""
    
    cmd = [ctx.env.SIZE[0], '--format', 'SysV', ctx.inputs[0].abspath()]
    
    result = subprocess.run(
        cmd,
        capture_output=True,
        text=True,
        check=True
    )
    
    # Filter .bss, .text, .rodata, .data
    print("---------------------------------------")
    for line in result.stdout.splitlines():
        if any(section in line for section in ('.bss', '.text', '.rodata', '.data', '.work')):
            print(line)
    print("---------------------------------------")
    return 0

Make sure to include import subprocess and set the SIZE environment variable.
You can call it after the build with:

bld(rule=size_sysv_print, source=f'{app_name}.elf', always=True)

Output example:

$ sys/waf
Waf: Entering directory `C:/msys64/home/SimTech/rtems-workspace/at32_os/build/arm-rtems7-at32f4'
[5/5] Processing build/arm-rtems7-at32f4/app.elf
---------------------------------------
.text                  39756   134218560
.rodata                 7088   134258344
.data                    848   536871440
.bss                    5408   536872288
.work                5105472   536885440
---------------------------------------