* Migration of BSP from kirkstone to scarthgap : size of binaries increased a lot, why ? gcc ? relro option ?
@ 2025-04-24 15:11 Joel GUITTET
2025-04-26 18:17 ` [yocto] " Gyorgy Sarvari
0 siblings, 1 reply; 2+ messages in thread
From: Joel GUITTET @ 2025-04-24 15:11 UTC (permalink / raw)
To: yocto
[-- Attachment #1: Type: text/plain, Size: 7527 bytes --]
Hello,
We are currently migrating a BSP from kirkstone 4.0.17 to scarthgap 5.0.8.
We observed the size of the BSP has increased a lot. It becomes a problem as the QSPI size is limited, so increasing the size of the BSP means less free space for the app.
After a small investigation we observed not a lot of changes in the rootfs. The main reason the BSP is growing is the size of the binaries is growing (executable and libraries).
It seams an extra padding has been added with scarthgap.
Example with an objdump -h of libattr.so.1.1.2501 on scarthgap:
>
>
> Sections:
> Idx Name Size VMA LMA File off
> Algn
> 0 .note.gnu.property 00000020 0000000000000238 0000000000000238
> 00000238 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 1 .note.gnu.build-id 00000024 0000000000000258 0000000000000258
> 00000258 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 2 .gnu.hash 00000178 0000000000000280 0000000000000280 00000280
> 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 3 .dynsym 000006a8 00000000000003f8 00000000000003f8 000003f8
> 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 4 .dynstr 0000027a 0000000000000aa0 0000000000000aa0 00000aa0
> 2**0
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 5 .gnu.version 0000008e 0000000000000d1a 0000000000000d1a 00000d1a
> 2**1
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 6 .gnu.version_d 000000a4 0000000000000da8 0000000000000da8 00000da8
> 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 7 .gnu.version_r 00000040 0000000000000e50 0000000000000e50 00000e50
> 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 8 .rela.dyn 00000108 0000000000000e90 0000000000000e90 00000e90
> 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 9 .rela.plt 000003f0 0000000000000f98 0000000000000f98 00000f98
> 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 10 .init 0000001c 0000000000001388 0000000000001388 00001388
> 2**2
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 11 .plt 000002c0 00000000000013b0 00000000000013b0 000013b0
> 2**4
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 12 .text 00002258 0000000000001670 0000000000001670 00001670
> 2**4
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 13 .fini 00000018 00000000000038c8 00000000000038c8 000038c8
> 2**2
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 14 .rodata 00000106 00000000000038e0 00000000000038e0 000038e0
> 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 15 .eh_frame_hdr 00000114 00000000000039e8 00000000000039e8 000039e8
> 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 16 .eh_frame 00000694 0000000000003b00 0000000000003b00 00003b00
> 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 17 .init_array 00000008 000000000001fc10 000000000001fc10 0000fc10
> 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 18 .fini_array 00000008 000000000001fc18 000000000001fc18 0000fc18
> 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 19 .dynamic 00000230 000000000001fc20 000000000001fc20 0000fc20
> 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 20 .got 000001b0 000000000001fe50 000000000001fe50 0000fe50
> 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 21 .data 00000008 0000000000020000 0000000000020000 00010000
> 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 22 .bss 00000010 0000000000020008 0000000000020008 00010008
> 2**3
> ALLOC
> 23 .gnu_debuglink 00000018 0000000000000000 0000000000000000 00010008
> 2**2
> CONTENTS, READONLY
>
>
The same objdump -h of libattr.so.1.1.2501 on kirkstone:
>
> Sections:
> Idx Name Size VMA LMA File off
> Algn
> 0 .note.gnu.property 00000020 0000000000000238 0000000000000238
> 00000238 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 1 .note.gnu.build-id 00000024 0000000000000258 0000000000000258
> 00000258 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 2 .gnu.hash 00000178 0000000000000280 0000000000000280 00000280
> 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 3 .dynsym 000006a8 00000000000003f8 00000000000003f8 000003f8
> 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 4 .dynstr 0000027a 0000000000000aa0 0000000000000aa0 00000aa0
> 2**0
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 5 .gnu.version 0000008e 0000000000000d1a 0000000000000d1a 00000d1a
> 2**1
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 6 .gnu.version_d 000000a4 0000000000000da8 0000000000000da8 00000da8
> 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 7 .gnu.version_r 00000040 0000000000000e50 0000000000000e50 00000e50
> 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 8 .rela.dyn 00000108 0000000000000e90 0000000000000e90 00000e90
> 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 9 .rela.plt 000003f0 0000000000000f98 0000000000000f98 00000f98
> 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 10 .init 0000001c 0000000000001388 0000000000001388 00001388
> 2**2
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 11 .plt 000002c0 00000000000013b0 00000000000013b0 000013b0
> 2**4
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 12 .text 000022d8 0000000000001670 0000000000001670 00001670
> 2**4
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 13 .fini 00000018 0000000000003948 0000000000003948 00003948
> 2**2
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 14 .rodata 00000106 0000000000003960 0000000000003960 00003960
> 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 15 .eh_frame_hdr 00000114 0000000000003a68 0000000000003a68 00003a68
> 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 16 .eh_frame 000006a4 0000000000003b80 0000000000003b80 00003b80
> 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 17 .init_array 00000008 0000000000014c10 0000000000014c10 00004c10
> 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 18 .fini_array 00000008 0000000000014c18 0000000000014c18 00004c18
> 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 19 .dynamic 00000230 0000000000014c20 0000000000014c20 00004c20
> 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 20 .got 000001b0 0000000000014e50 0000000000014e50 00004e50
> 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 21 .data 00000008 0000000000015000 0000000000015000 00005000
> 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 22 .bss 00000010 0000000000015008 0000000000015008 00005008
> 2**3
> ALLOC
> 23 .gnu_debuglink 00000018 0000000000000000 0000000000000000 00005008
> 2**2
> CONTENTS, READONLY
>
>
Difference at the init_array offset with about 50kB unused spaces, plenty of zeros in the binary.
Multiple executable/libraries with additional 50kB = several Mega Bytes.
I suspect the evolution of GCC is the cause of this difference (GCC11 vs GCC13), and I don't see any changes related to this in Yocto. I have to check if GCC changed his behavior or if some options have been introduced. Any flag we should add maybe in the build to keep small binaries in the rootfs ? I remember similar stuff related to relro option, not sure...
Thanks for the feedbacks!
Joel
[-- Attachment #2: Type: text/html, Size: 29929 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [yocto] Migration of BSP from kirkstone to scarthgap : size of binaries increased a lot, why ? gcc ? relro option ?
2025-04-24 15:11 Migration of BSP from kirkstone to scarthgap : size of binaries increased a lot, why ? gcc ? relro option ? Joel GUITTET
@ 2025-04-26 18:17 ` Gyorgy Sarvari
0 siblings, 0 replies; 2+ messages in thread
From: Gyorgy Sarvari @ 2025-04-26 18:17 UTC (permalink / raw)
To: yocto, jguittet.opensource
On 4/24/25 17:11, Joel GUITTET via lists.yoctoproject.org wrote:
> Hello,
>
> We are currently migrating a BSP from kirkstone 4.0.17 to scarthgap 5.0.8.
> We observed the size of the BSP has increased a lot. It becomes a
> problem as the QSPI size is limited, so increasing the size of the BSP
> means less free space for the app.
> After a small investigation we observed not a lot of changes in the
> rootfs. The main reason the BSP is growing is the size of the binaries
> is growing (executable and libraries).
> It seams an extra padding has been added with scarthgap.
>
> Example with an objdump -h of libattr.so.1.1.2501 on scarthgap:
>
>
>
> Sections:
> Idx Name Size VMA LMA
> File off Algn
> 0 .note.gnu.property 00000020 0000000000000238
> 0000000000000238 00000238 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 1 .note.gnu.build-id 00000024 0000000000000258
> 0000000000000258 00000258 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 2 .gnu.hash 00000178 0000000000000280 0000000000000280
> 00000280 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 3 .dynsym 000006a8 00000000000003f8 00000000000003f8
> 000003f8 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 4 .dynstr 0000027a 0000000000000aa0 0000000000000aa0
> 00000aa0 2**0
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 5 .gnu.version 0000008e 0000000000000d1a 0000000000000d1a
> 00000d1a 2**1
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 6 .gnu.version_d 000000a4 0000000000000da8 0000000000000da8
> 00000da8 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 7 .gnu.version_r 00000040 0000000000000e50 0000000000000e50
> 00000e50 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 8 .rela.dyn 00000108 0000000000000e90 0000000000000e90
> 00000e90 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 9 .rela.plt 000003f0 0000000000000f98 0000000000000f98
> 00000f98 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 10 .init 0000001c 0000000000001388 0000000000001388
> 00001388 2**2
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 11 .plt 000002c0 00000000000013b0 00000000000013b0
> 000013b0 2**4
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 12 .text 00002258 0000000000001670 0000000000001670
> 00001670 2**4
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 13 .fini 00000018 00000000000038c8 00000000000038c8
> 000038c8 2**2
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 14 .rodata 00000106 00000000000038e0 00000000000038e0
> 000038e0 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 15 .eh_frame_hdr 00000114 00000000000039e8 00000000000039e8
> 000039e8 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 16 .eh_frame 00000694 0000000000003b00 0000000000003b00
> 00003b00 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 17 .init_array 00000008 000000000001fc10 000000000001fc10
> 0000fc10 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 18 .fini_array 00000008 000000000001fc18 000000000001fc18
> 0000fc18 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 19 .dynamic 00000230 000000000001fc20 000000000001fc20
> 0000fc20 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 20 .got 000001b0 000000000001fe50 000000000001fe50
> 0000fe50 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 21 .data 00000008 0000000000020000 0000000000020000
> 00010000 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 22 .bss 00000010 0000000000020008 0000000000020008
> 00010008 2**3
> ALLOC
> 23 .gnu_debuglink 00000018 0000000000000000 0000000000000000
> 00010008 2**2
> CONTENTS, READONLY
>
>
>
> The same objdump -h of libattr.so.1.1.2501 on kirkstone:
>
>
> Sections:
> Idx Name Size VMA LMA
> File off Algn
> 0 .note.gnu.property 00000020 0000000000000238
> 0000000000000238 00000238 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 1 .note.gnu.build-id 00000024 0000000000000258
> 0000000000000258 00000258 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 2 .gnu.hash 00000178 0000000000000280 0000000000000280
> 00000280 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 3 .dynsym 000006a8 00000000000003f8 00000000000003f8
> 000003f8 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 4 .dynstr 0000027a 0000000000000aa0 0000000000000aa0
> 00000aa0 2**0
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 5 .gnu.version 0000008e 0000000000000d1a 0000000000000d1a
> 00000d1a 2**1
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 6 .gnu.version_d 000000a4 0000000000000da8 0000000000000da8
> 00000da8 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 7 .gnu.version_r 00000040 0000000000000e50 0000000000000e50
> 00000e50 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 8 .rela.dyn 00000108 0000000000000e90 0000000000000e90
> 00000e90 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 9 .rela.plt 000003f0 0000000000000f98 0000000000000f98
> 00000f98 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 10 .init 0000001c 0000000000001388 0000000000001388
> 00001388 2**2
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 11 .plt 000002c0 00000000000013b0 00000000000013b0
> 000013b0 2**4
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 12 .text 000022d8 0000000000001670 0000000000001670
> 00001670 2**4
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 13 .fini 00000018 0000000000003948 0000000000003948
> 00003948 2**2
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 14 .rodata 00000106 0000000000003960 0000000000003960
> 00003960 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 15 .eh_frame_hdr 00000114 0000000000003a68 0000000000003a68
> 00003a68 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 16 .eh_frame 000006a4 0000000000003b80 0000000000003b80
> 00003b80 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 17 .init_array 00000008 0000000000014c10 0000000000014c10
> 00004c10 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 18 .fini_array 00000008 0000000000014c18 0000000000014c18
> 00004c18 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 19 .dynamic 00000230 0000000000014c20 0000000000014c20
> 00004c20 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 20 .got 000001b0 0000000000014e50 0000000000014e50
> 00004e50 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 21 .data 00000008 0000000000015000 0000000000015000
> 00005000 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 22 .bss 00000010 0000000000015008 0000000000015008
> 00005008 2**3
> ALLOC
> 23 .gnu_debuglink 00000018 0000000000000000 0000000000000000
> 00005008 2**2
> CONTENTS, READONLY
>
>
>
> Difference at the init_array offset with about 50kB unused spaces,
> plenty of zeros in the binary.
> Multiple executable/libraries with additional 50kB = several Mega Bytes.
>
> I suspect the evolution of GCC is the cause of this difference (GCC11
> vs GCC13), and I don't see any changes related to this in Yocto. I
> have to check if GCC changed his behavior or if some options have been
> introduced. Any flag we should add maybe in the build to keep small
> binaries in the rootfs ? I remember similar stuff related to relro
> option, not sure...
Is it possible that you have stumbled upon a fix[1] for a binutils
issue[2]? It does pad relro segment with 0s up to the next MAXPAGESIZE
boundary, and was added in version 2.39 - ~50kB extra sounds about right
on some arches.
If this is what you found, then unfortunately it's like that. There is a
bug[3] for binutils to fix this size increase, but when/if there will
there be any outcome, is hard to tell.
You can easily verify if this is really what's affecting you by testing
it with reverting this commit, but reverting it permanently wouldn't be
wise considering that it's a security fix at its heart.
[1]:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9833b7757d246f22db4eb24b8e5db7eb5e05b6d9
[2]: https://sourceware.org/bugzilla/show_bug.cgi?id=28824
[3]: https://sourceware.org/bugzilla/show_bug.cgi?id=30612
>
> Thanks for the feedbacks!
> Joel
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#65244): https://lists.yoctoproject.org/g/yocto/message/65244
> Mute This Topic: https://lists.yoctoproject.org/mt/112434747/6084445
> Group Owner: yocto+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [skandigraun@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2025-04-26 18:17 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-04-24 15:11 Migration of BSP from kirkstone to scarthgap : size of binaries increased a lot, why ? gcc ? relro option ? Joel GUITTET
2025-04-26 18:17 ` [yocto] " Gyorgy Sarvari
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.