The GNU strip tool supports remove debug sections by default, there are cases where we want to specify by default a section be striped out or be persistent, for example .CTF section is thinking to be present after strip invocation so it could be mark as persistent, but note sections for example are not needed at run-time, so it is a candidate to be stripped out. So this bugzilla is for adding support in binutils tools to indicate when a section should be stripped out or it must be persistent by default, using GNU strip tool, adding/reusing new section attributes.
What's special about .CTF sections?
(In reply to Guillermo E. Martinez from comment #0) Hi Guillermo, > So this bugzilla is for adding support in binutils tools to indicate when a > section should be stripped out or it must be persistent by default, using > GNU strip tool, adding/reusing new section attributes. The strip tool already has the --keep-section=<NAME> command line option to specify that section <NAME> should not be stripped. Similarly it also has --remove-section=<NAME> to specify that <NAME> must be removed. Are you asking for strip to be able to keep or remove sections based upon their attributes, rather than their names ? I fail to see the utility of this, but perhaps you could provide an example of how it might work ? Cheers Nick
(In reply to Andreas Schwab from comment #1) Hi Andreas, > What's special about .CTF sections? Nothing special with .CTF section, I just quoted it, because it's an example of a section that should be kept after execute GNU strip, it does so, but attending the discussion posted here: https://sourceware.org/pipermail/elfutils-devel/2022q2/005114.html Where we're looking for a standard way to indicates whether sections should be preserved or not after GNU strip execution, so we don't need special arguments. Kind regards, guillermo
(In reply to Nick Clifton from comment #2) > (In reply to Guillermo E. Martinez from comment #0) > Hi Guillermo, > Hi Nick, > > So this bugzilla is for adding support in binutils tools to indicate when a > > section should be stripped out or it must be persistent by default, using > > GNU strip tool, adding/reusing new section attributes. > > The strip tool already has the --keep-section=<NAME> command line option to > specify that section <NAME> should not be stripped. Similarly it also has > --remove-section=<NAME> to specify that <NAME> must be removed. > Yes, correct. > Are you asking for strip to be able to keep or remove sections based upon > their attributes, rather than their names ? I fail to see the utility of > this, but perhaps you could provide an example of how it might work ? > Exactly. This bugzilla is to provide the feedback and support triggered by the discussion for standardize a way to indicates whether sections should be preserved or not after binutils strip/eu-strip execution without need to use special arguments, details here: https://sourceware.org/pipermail/elfutils-devel/2022q2/005114.html > Cheers > Nick Best regards, guillermo
(In reply to Guillermo E. Martinez from comment #4) Hi Guillermo, > > Are you asking for strip to be able to keep or remove sections based upon > > their attributes, rather than their names ? > > Exactly. This bugzilla is to provide the feedback and support triggered by > the discussion for standardize a way to indicates whether sections should be > preserved or not after binutils strip/eu-strip execution without need to use > special arguments, OK, so lets assume that we restrict this to ELF format files only. Basically the idea is, (I think...), we define a new section flag, eg: SHF_GNU_CAN_BE_STRIPPED which would be set by the linker on any section that it believes is not necessary for proper execution of the binary. (ie debug info sections, notes that are not needed by the loader, etc). In addition tools like objcopy should be able to add or remove this flag from specific sections at the behest of the user. The purpose of the flag is to tell tools like strip and eu-strip that the section can and should be removed or preserved when stripping or creating a debuginfo file. (At the moment this decision is made by heuristics built into these tools, and the heuristics differ...) In order to support backwards compatibility with files that do not use this scheme, it will probably also be necessary to define a second flag: SHF_GNU_DO_NOT_STRIP Then the tools can detect sections which have not been annotated with this new feature and fall back on their old heuristics instead. ------------------------------------------------------------------------- Does that sound about right ? If so then I think that the proper way to proceed with this idea is to present it on the GNU gABI list (gnu-gabi@sourceware.org) rather than discussing it inside a binutils PR. Do you agree ? Cheers Nick
(In reply to Nick Clifton from comment #5) > (In reply to Guillermo E. Martinez from comment #4) > Hi Guillermo, > Hi Nick, > > > Are you asking for strip to be able to keep or remove sections based upon > > > their attributes, rather than their names ? > > > > Exactly. This bugzilla is to provide the feedback and support triggered by > > the discussion for standardize a way to indicates whether sections should be > > preserved or not after binutils strip/eu-strip execution without need to use > > special arguments, > > OK, so lets assume that we restrict this to ELF format files only. > > Basically the idea is, (I think...), we define a new section flag, eg: > > SHF_GNU_CAN_BE_STRIPPED > > which would be set by the linker on any section that it believes is not > necessary for proper execution of the binary. (ie debug info sections, > notes that are not needed by the loader, etc). In addition tools like > objcopy should be able to add or remove this flag from specific > sections at the behest of the user. > Yes, that's right. > The purpose of the flag is to tell tools like strip and eu-strip that the > section can and should be removed or preserved when stripping or creating > a debuginfo file. (At the moment this decision is made by heuristics > built into these tools, and the heuristics differ...) > Yes. So basically sections in binutils strip are removed whether SEC_DEBUGGING is set, it happens because section name contains: .debug, .gnu.debuglto_.debug_,.gnu.linkonce.wi., .zdebug, .line, .stab, .gdb_index, excluding: .gnu_debuglink and .gnu_debugaltlink. So, there is not a section attribute to indicates if this section will removed or preserved. > In order to support backwards compatibility with files that do not use > this scheme, it will probably also be necessary to define a second flag: > > SHF_GNU_DO_NOT_STRIP > Yes, I think so. > Then the tools can detect sections which have not been annotated with this > new feature and fall back on their old heuristics instead. > Correct. > ------------------------------------------------------------------------- > > Does that sound about right ? > Yes!. > If so then I think that the proper way to proceed with this idea is to > present it on the GNU gABI list (gnu-gabi@sourceware.org) rather than > discussing it inside a binutils PR. Do you agree ? > Agree, of course!. What will be next step to start working on it? > Cheers > Nick Thanks Nick, guillermo
(In reply to Guillermo E. Martinez from comment #6) > Agree, of course!. What will be next step to start working on it? I have started a discussion on this topic on the gun-gabi mailing list. (Unfortunately I do not seem to be able to find a URL to link to the discussion). At the moment the issue appears to be that just having two flag bits is not enough to express all the situations when a section should, or should not be stripped. But there is only a very limited number of bits available as section flags, so maybe another mechanism should be used.
Sorry - I do not think that this is going to happen. Using section flags has been vetoed because there are too many different ways to strip a binary, and not enough flags to encompass them all. Using extended section types might help, but even then you need to persuade the maintainers of all the different strip tools to agree on which section types map to which stripping modes. Plus when new section types are added you have to go through the whole process again. All of the strip tools do provide mechanisms for explicitly specifying which sections should be removed, so for now that will have to do.
(In reply to Nick Clifton from comment #8) Hello Nick, > Sorry - I do not think that this is going to happen. > OK. I see, but I made a really big mistake because my original perception was that eu-strip removes .ctf section, but it doesn't, because it doesn't have a "debug" section name. > Using section flags has been vetoed because there are too many different > ways to strip a binary, and not enough flags to encompass them all. > Even though, if we want remove by default a section, it should be specially named (`dwarf_scn_names'). > Using extended section types might help, but even then you need to persuade > the maintainers of all the different strip tools to agree on which section > types map to which stripping modes. Plus when new section types are added > you have to go through the whole process again. > > All of the strip tools do provide mechanisms for explicitly specifying which > sections should be removed, so for now that will have to do. OK, good. Thanks, and sorry for my misunderstanding. guillermo