Executable Size Info Question

[Joel Sherrill]

On Sat, Jan 24, 2026 at 9:23 PM Alan Modra <amodra@gmail.com> wrote:

> On Sat, Jan 24, 2026 at 01:28:25PM -0600, Joel Sherrill wrote:
> > Hi
> >
> > Over at RTEMS, I started investigating BSPs where size is confused and
> > reports large sizes for .bss which appear to be close to the actual
> > physical memory size on the target board. This seems to happen when the
> > BSP's linker script does not have the expected bss start and end symbols.
> > About half of the 13 architectures supported by RTEMS have at least one
> BSP
> > with this problem.
> >
> > Picking one at random, this is what size reports:
> >
> > aarch64-a53_lp64_qemu: 103014       2080    134078296    134183390
> >  7ff79de   hello.exe
> >
> > This is what rtems-exeinfo reports for the .bss size
> >
> >  .bss               WA------------ addr: 0x401007c0 0x40103488 size:
> >  11464 align:  64 relocs:      0
> >
> > And this is what readelf -S reports
> >
> > [18] .bss              NOBITS           00000000401007c0  00030798
> >        0000000000002cc8  0000000000000000  WA       0     0     64
> >
> > I have cc'ed Chris Johns who wrote rtems-exeinfo. Hopefully he can help
> > explain why the rtems-exeinfo section information does not match readelf.
> >
> > size appears to look for bss start and end symbols which are architecture
> > specific to get the size. If this correct, is there a list of what
> symbols
> > are needed?
>
> No it doesn't.  In the default berkely mode, binutils size sums
> allocated sections without contents, and prints that size under the
> bss heading.  I expect you have other sections beside .bss that match
> the alloc and no contents test.
>

Thanks Alan. I was hoping that me or someone else would get a chance
to try to fix this on one of the BSPs but that hasn't happened yet.

I have attached the linker script files from an aarch64 BSP. I hope you
can take a look at them and spot our mistake.

We use templated linkcmds like this on newer BSPs because copy/paste
of linker scripts leads to inconsistencies and technical debt as things
evolve.

Any help is appreciated.

--joel


>
> > If this isn't documented, which installed linker script for is best to
> look
> > at? Or which suffix indicates the linker script used to link executables.
> >
> > I assume we will have to fix BSP linker scripts one at a time until size
> > reports a reasonable value but it would be nice to know what size looks
> for
> > so we can ensure size informatoin is correct.
> >
> > Thanks.
> >
> > --joel
>
> --
> Alan Modra
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20260127/b4f4ce5e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linkcmds
Type: application/octet-stream
Size: 2747 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20260127/b4f4ce5e/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linkcmds.base
Type: application/octet-stream
Size: 16975 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20260127/b4f4ce5e/attachment-0003.obj>