https://sourceware.org/bugzilla/show_bug.cgi?id=33344
Rin Okuyama <rokuyama.rk at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|NOTABUG |---
Status|RESOLVED |REOPENED
--- Comment #8 from Rin Okuyama <rokuyama.rk at gmail dot com> ---
(In reply to H.J. Lu from comment #6)
> (In reply to Rin Okuyama from comment #5)
> > (In reply to H.J. Lu from comment #4)
> > > (In reply to H.J. Lu from comment #3)
> > > > (In reply to Rin Okuyama from comment #0)
> > > > > You can see the size of segment is not changed at all. This results in
> > > > > regression of stripped-binary sizes for NetBSD.
> > > >
> > > > Did you mean segment size, not file size?
> > >
> > > The segment size difference is kind of random. Please compare segment
> > > sizes for "strip -R .note.netbsd.ident -R .note.netbsd.pax" with binutils
> > > 2.42 and 2.45.
> >
> > What we are concerned about is the binary size.
> >
> > I mentioned the segment size as a cause of increase in the binary size.
> >
>
> I saw:
>
> [hjl@gnu-cfl-3 bug33344]$ ls -l
> total 80
> -rwxr-xr-x 1 hjl hjl 22072 Aug 31 03:25 hello.242
> -rwxr-xr-x 1 hjl hjl 11568 Aug 31 03:25 hello.242.stripped
> -rwxr-xr-x 1 hjl hjl 22088 Aug 31 03:28 hello.245
> -rwxr-xr-x 1 hjl hjl 11608 Aug 31 03:28 hello.245.stripped
> -rw-r--r-- 1 hjl hjl 79 Aug 31 03:24 hello.c
> -rw-r--r-- 1 hjl hjl 1288 Aug 31 03:24 hello.o
> [hjl@gnu-cfl-3 bug33344]$
>
> The 2.45 file size increased slightly due to different section layouts.
No, this is not due to section layouts; the difference scales with
.eh_frame and .eh_frame_hdr.
For dynamically-linked binaries, .eh_frame{,_hdr} are small, and
difficult to recognize due to alignments b/w segments.
I've uploaded statically-linked versions as a better example:
```
% ls -l *.stripped
-rwxr-xr-x 1 rin wsrc 745816 Sep 4 14:35 static.242.stripped
-rwxr-xr-x 1 rin wsrc 799128 Sep 4 14:35 static.245.stripped
```
These are stripped binaries with `strip -R .eh_frame -R .eh_frame_hdr`.
This difference cannot be explained only by section layouts.
Let us see sections for binaries before/after strip(1):
```
% readelf -l static.245
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
...
[ 4] .rodata PROGBITS 000000000049f000 0009f000
0000000000006ac8 0000000000000000 A 0 0 32
[ 5] .eh_frame PROGBITS 00000000004a5ac8 000a5ac8
000000000000d7d4 0000000000000000 A 0 0 8
[ 6] .note.netbsd[...] NOTE 00000000004b329c 000b329c
0000000000000018 0000000000000000 A 0 0 4
...
% readelf -l static.245.stripped
...
[ 4] .rodata PROGBITS 000000000049f000 0009f000
0000000000006ac8 0000000000000000 A 0 0 32
[ 5] .note.netbsd[...] NOTE 00000000004b329c 000b329c
0000000000000018 0000000000000000 A 0 0 4
...
```
Here, offset of .note.netbsd.ident is not changed even though
.eh_frame is stripped.
hexdump(1) shows that .eh_frame section is zero-cleared for
stripped binary.
```
% hexdump -C static.245.stripped
...
000a5ac0 75 d4 fe ff 5d d6 fe ff 00 00 00 00 00 00 00 00 |u...]...........|
000a5ad0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000b3290 00 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 |................|
000b32a0 04 00 00 00 01 00 00 00 4e 65 74 42 53 44 00 00 |........NetBSD..|
...
```
strip(1) cannot remove .eh_frame because .note.netbsd.ident is
behind .eh_frame, and offset of the former should be conserved.
Note that for statically-linked binaries, .eh_frame_hdr is not present,
but it is for dynamically-linked binaries.
--
You are receiving this mail because:
You are on the CC list for the bug.
