https://sourceware.org/bugzilla/show_bug.cgi?id=29737
--- Comment #6 from Guillermo E. Martinez <guillermo.e.martinez at oracle dot com> --- (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-g...@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 -- You are receiving this mail because: You are on the CC list for the bug.
