Using section flags to indicate stripable or persistent sections

Using section flags to indicate stripable or persistent sections

[Nick Clifton]

Hi Guys,

     We would like to suggest an extension the ELF section flags which can be
     used to indicate sections that should, or should not, be stripped when
     removing debug information.

     The problem we are trying to address is that different stripping tools
     (strip, eu-strip, llvm-strip) have different heuristics for deciding
     which sections should be removed when stripping debug information.  In
     order to fix this we are proposing two new section flags:

       GNU_SHF_CAN_BE_STRIPPED
       GNU_SHF_DO_NOT_STRIP

     These would be set by the assembler and/or linker to indicate sections
     that should be removed when stripping and sections which must not be
     removed when stripping.  It would be an error if both flags were present
     on a given section, and if neither flag is present then the stripping
     tool would fall back on its built in heuristics.

     In addition we need new flags for the assembler's .section directive
     (suggestion: 'D': can be stripped, 'K' do not strip).
     This email is to ask if you think that this idea has merit, and if so,
     are there any guidelines for writing and submitting a formal specification ?

  Cheers
     Nick

Re: Using section flags to indicate stripable or persistent sections

[Michael Matz]

Hey,

On Mon, 7 Nov 2022, Nick Clifton via Gnu-gabi wrote:

>     We would like to suggest an extension the ELF section flags which can be
>     used to indicate sections that should, or should not, be stripped when
>     removing debug information.

Okay, so stripping of sections intended for debug purposes ...

>     The problem we are trying to address is that different stripping tools
>     (strip, eu-strip, llvm-strip) have different heuristics for deciding
>     which sections should be removed when stripping debug information.  In
>     order to fix this we are proposing two new section flags:
> 
>       GNU_SHF_CAN_BE_STRIPPED
>       GNU_SHF_DO_NOT_STRIP

... but here you have "can be stripped?".  The immediate question is: for 
which purposes?  A section might be strippable in other context than debug 
info.  And other sections might be non-strippable for still other 
purposes.  Just saying "please don't strip this one" conveys no useful 
information, except of course to inhibit each and all stripping.  But was 
it perhaps set for other reasons than debug info?  Even with those flags 
tools will continue to wonder if maybe this-and-that DO_NOT_STRIP option 
can actually be stripped in some cases.

IOW: if you really want what you said, make the flags more specific (to 
debug info purposes).  But then of course it's unclear why you wouldn't 
want still other flags to mean "strip-for-something-else" purposes.  At 
which point you quickly come to the conclusion that one wants to specify 
some sort of type per section, and not lump everything under SHT_PROGBITS.

So, I think two flag bits are not the right solution.  Maybe we could use 
some bits of sh_type to specify a more detailed type: the low bits would 
just be set to the ELF SHT_xxx as appropriate, and higher bits would 
contain a detailed type:

  0x60XXYYZZ

(ZZ would be the old SHT_xxx type, and XX/YY be a detail type).


Ciao,
Michael.

> 
>     These would be set by the assembler and/or linker to indicate sections
>     that should be removed when stripping and sections which must not be
>     removed when stripping.  It would be an error if both flags were present
>     on a given section, and if neither flag is present then the stripping
>     tool would fall back on its built in heuristics.
> 
>     In addition we need new flags for the assembler's .section directive
>     (suggestion: 'D': can be stripped, 'K' do not strip).
>     This email is to ask if you think that this idea has merit, and if so,
>     are there any guidelines for writing and submitting a formal specification
> ?
> 
>  Cheers
>     Nick
> 

Re: Using section flags to indicate stripable or persistent sections

[Fangrui Song]

On 2022-11-07, Michael Matz via Gnu-gabi wrote:
>Hey,
>
>On Mon, 7 Nov 2022, Nick Clifton via Gnu-gabi wrote:
>
>>     We would like to suggest an extension the ELF section flags which can be
>>     used to indicate sections that should, or should not, be stripped when
>>     removing debug information.
>
>Okay, so stripping of sections intended for debug purposes ...
>
>>     The problem we are trying to address is that different stripping tools
>>     (strip, eu-strip, llvm-strip) have different heuristics for deciding
>>     which sections should be removed when stripping debug information.  In
>>     order to fix this we are proposing two new section flags:
>>
>>       GNU_SHF_CAN_BE_STRIPPED
>>       GNU_SHF_DO_NOT_STRIP
>
>... but here you have "can be stripped?".  The immediate question is: for
>which purposes?  A section might be strippable in other context than debug
>info.  And other sections might be non-strippable for still other
>purposes.  Just saying "please don't strip this one" conveys no useful
>information, except of course to inhibit each and all stripping.  But was
>it perhaps set for other reasons than debug info?  Even with those flags
>tools will continue to wonder if maybe this-and-that DO_NOT_STRIP option
>can actually be stripped in some cases.
>
>IOW: if you really want what you said, make the flags more specific (to
>debug info purposes).  But then of course it's unclear why you wouldn't
>want still other flags to mean "strip-for-something-else" purposes.  At
>which point you quickly come to the conclusion that one wants to specify
>some sort of type per section, and not lump everything under SHT_PROGBITS.
>
>So, I think two flag bits are not the right solution.  Maybe we could use
>some bits of sh_type to specify a more detailed type: the low bits would
>just be set to the ELF SHT_xxx as appropriate, and higher bits would
>contain a detailed type:
>
>  0x60XXYYZZ
>
>(ZZ would be the old SHT_xxx type, and XX/YY be a detail type).
>
>
>Ciao,
>Michael.

Agree that the different purposes can be difficult to capture with just
one or two bits. As a concrete example, llvm-strip/llvm-objcopy has this
piece of logic for various --strip-* modes: --strip-dwo, --strip-debug,
--strip-sections, --strip-all-gnu, --strip-all
https://github.com/llvm/llvm-project/blob/c997fe658655b42237f556c11c7f5bc8ec60658b/llvm/lib/ObjCopy/ELF/ELFObjcopy.cpp#L380-L446

--strip-all-gnu exists because it is determined GNU strip's default
--strip-all doesn't strip all :( https://github.com/llvm/llvm-project/commit/6ad72d05f5ebaada700487d3d0fe1d107b32468a

I feel that whether .ctf is strippable in various strip modes may be a
related question. (I tend to suggest a more intuitive rule instead of
doing some magic to ease the adoption of a new section. Let users do
--keep-section=xxx for new sections.)

>>
>>     These would be set by the assembler and/or linker to indicate sections
>>     that should be removed when stripping and sections which must not be
>>     removed when stripping.  It would be an error if both flags were present
>>     on a given section, and if neither flag is present then the stripping
>>     tool would fall back on its built in heuristics.
>>
>>     In addition we need new flags for the assembler's .section directive
>>     (suggestion: 'D': can be stripped, 'K' do not strip).
>>     This email is to ask if you think that this idea has merit, and if so,
>>     are there any guidelines for writing and submitting a formal specification
>> ?
>>
>>  Cheers
>>     Nick
>>

Re: Using section flags to indicate stripable or persistent sections

[Alan Modra]

On Mon, Nov 07, 2022 at 10:51:36AM -0800, Fangrui Song wrote:
> I feel that whether .ctf is strippable in various strip modes may be a
> related question. (I tend to suggest a more intuitive rule instead of
> doing some magic to ease the adoption of a new section. Let users do
> --keep-section=xxx for new sections.)

I agree.  I think new SHF flags should only be added if there is a
really desperate need for them, or when everyone sees them as such an
elegant solution to a big problem that we all say "Why didn't I think
of that before?"

-- 
Alan Modra
Australia Development Lab, IBM

Re: Using section flags to indicate stripable or persistent sections

[Nick Clifton]

Hi Guys,

   OK, I agree that using the section flags is a bad idea.

   Using an extended section types is a nice idea, but I think that
   it will probably not solve the underlying problem of inconsistent
   section stripping - we would still need to persuade the tool
   maintainers to agree on which section types are stripped with each
   given strip option, and when new types are added the options would
   have to be updated.

   For now I think that the KISS principle applies.  The strip tools
   have methods for explicitly specifying which sections should be
   removed, so whilst it might be a bit cumbersome if lots of sections
   have to specified, it can be done.

   Extension suggestion withdrawn.

Cheers
   Nick