Abdullah Wasiq commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5191#note_143447 I've been interested in this issue for a bit. I came across the binutils mailing list (over [here](https://sourceware.org/pipermail/binutils/2026-January/147930.html)) and it seems the issue may not have to do with .bss end/start symbols at all. The aarch64 BSP linkcmds has this: `RAM : ORIGIN = 1073741824 + 32768, LENGTH = 134217728 - 32768 - 1048576` This is about 127 MB of RAM. Does this mean a section of RAM being empty at runtime, is the culprit here? I did some research, and correct me if i'm wrong, but it seems in the Berkeley mode, size uses flags to fill up the space, ALLOC & NOBITS, in the .bss component. However, if you have additional special sections of RAM like .work & .stack (what I noticed specifically in the linkcmds.base as potential contenders for the garbage memory), and if these sections are set to alloc but contain no data, their sizes will be put into .bss. Specifically for .work, it seems to allocate all remaining RAM into it, meaning it could very well pass the entire allocated RAM as .bss: `. += ORIGIN (REGION_WORK) + LENGTH (REGION_WORK) - ABSOLUTE (.);` So this basically means the size util adds .work, .stack, and .bss then "passes" it completely as .bss. Maybe this is why .bss reported by size is close to the total RAM allocated? @joel Do you think there are other ways to approach this? Or is this issue something deeper now? -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5191#note_143447 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
