This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Should strip discard the .ctf section ?
- From: Fangrui Song <i at maskray dot me>
- To: Nick Alcock <nick dot alcock at oracle dot com>
- Cc: Nick Clifton <nickc at redhat dot com>, "Jose E. Marchesi" <jose dot marchesi at oracle dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Thu, 3 Oct 2019 04:26:05 +0000
- Subject: Re: Should strip discard the .ctf section ?
- References: <20190906225520.169680-1-nick.alcock@oracle.com> <20190906225520.169680-26-nick.alcock@oracle.com> <20190909004246.GN30165@bubble.grove.modra.org> <87k1a2eix0.fsf@esperi.org.uk> <8e0b48b9-8854-153a-9657-03364f899e97@redhat.com> <87v9thdbce.fsf@esperi.org.uk> <85d68fb7-f128-daf6-f943-0c4018bfd307@redhat.com> <87d0ff6rbf.fsf@esperi.org.uk>
On 2019-10-02, Nick Alcock wrote:
On 2 Oct 2019, Nick Clifton said:
Hi Nick,
The section is basically useless if strip removes it, so I'd vote no.
(That's the entire reason for the focus on size in CTF.)
Ok, well I will shelve the idea for now. But it may have to be revisited
if we start to get complaints/bug-reports from users.
If they're complaining, I need to make CTF smaller :P (plans are afoot:
it is expected to shrink :) ).
But yes, if they want literally no growth@all... one wonders if they
can ever upgrade anything ever, but still. :)
I'd vote for yes. Don't invent more customized rules for
--strip-debug/--strip-all. Just let them do natural things that meet
users' intuition.
Add a generic --keep-section option and let user specify
--keep-section=.ctf if .ctf is to be retained. See
https://llvm.org/docs/CommandGuide/llvm-objcopy.html#cmdoption-llvm-objcopy-keep-section
What sections are stripped and what are not are pretty complicated now.
FWIW, in llvm-objcopy, --strip-all-gnu is a separate option because
developers find --strip-all is a misnomer, so --strip-all does what they
think intuitive, while --strip-all-gnu is for binutils compatibility.
See http://reviews.llvm.org/rL319071. (courtesy of GCC/LLVM
Collaboration BoF)