https://sourceware.org/bugzilla/show_bug.cgi?id=34097
--- Comment #11 from Vitaly Chikunov <vt at altlinux dot org> ---
(In reply to Mark Wielaard from comment #9)
> (In reply to Vitaly Chikunov from comment #8)
> > I think the intent of our use of --strip-all is to maximize binary size
> > reduction.
>
> OK, but does it actually do that? It seems, at least for eu-strip, it is a
> noop, so it does less stripping than if you give it -g.
I think our --strip-all is a legacy from binutils strip -s.
But why it does less stripping than -g? I think 'debug only' should be
logically less than 'all'.
If we assume these options are compatibility with binutils, strip(1)
says
--strip-debug
Remove debugging symbols only.
--strip-all
Remove all symbols.
And, perhaps, it's implied that --strip-all is even stronger than
default strip.
> > If we do -g *globally* just to workaround the bug this will be suboptimal
> > and would increase sizes of binaries and non-debugging packages.
>
> Do you happen to have stats?
I just experimented stripping all .ko modules from 6.18 tree:
# Unstripped
6216550481
/usr/src/tmp/kernel-image-6.18-buildroot/lib/modules/6.18.24-6.18-alt1/kernel
# eu-strip --strip-debug --keep-section=.BTF
2000695738
/usr/src/tmp/kernel-image-6.18-buildroot/lib/modules/6.18.24-6.18-alt1/kernel
# eu-strip --strip-all --keep-section=.BTF
1998758461
/usr/src/tmp/kernel-image-6.18-buildroot/lib/modules/6.18.24-6.18-alt1/kernel
Yes, the difference is not very big. (But the same brp tooling is used
for all other ELFs in ALT, besides kernel modules, and I don't have stats
for that at hand).
In comparison with binutils strip
# strip --strip-all --keep-section=.BTF
1932219905
/usr/src/tmp/kernel-image-6.18-buildroot/lib/modules/6.18.24-6.18-alt1/kernel
> I am still trying to figure out what the intent of --strip-all is.
> We might want to implement it properly for eu-strip, but I don't fully
> understand what it is supposed to do.
Perhaps, the same as for binutils strip?
> > But we can switch to -g for these particular files of course.
> >
> > The file list looks accidental, though. For Linux 6.18 it's just 7 modules
> > in drivers/mtd/tests (which I disabled with CONFIG_MTD_TESTS=n). But for
> > 6.12 it's also lib/crypto/libcurve25519.ko and I am unsure (yet) it will not
> > appear in the other files on another build.
>
> O, that is interesting. So it actually works fine on most .ko files?
Yes. Now I convinced that this is the ordering issues Gleb described in
the previous email, related to the new binutils version (not to gcc15 as
I thought before).
> Do you happen to see a difference between these files?
> Could you maybe attach a "working" one?
> Maybe a pre-6.12 libcurve25519.ko that works and a 6.12 libcurve25519.ko
> that doesn't?
Please tell if it's still useful to attach non-failing version of
`libcurve25519.ko` (I will need to rebuild kernel with the old toolchain
for this).
--
You are receiving this mail because:
You are on the CC list for the bug.
