RFC: Mark a section to be discarded for DSO and executable

[H. J. Lu]

With LTO, an object file may contain sections with IL, which
can be discarded when building DSO and executable. Currently we can't
mark such sections with gABI. With GNU linker, we can use a
linker script to discard such sections. But it will be more generic
to make a section to be discarded for DSO and executable in gABI.
In that case, we don't need a special linker script to discard
such sections. Something like

#define SHF_DISCARD 0x800

would work.

H.J.

[H. J. Lu]

On Tue, Jan 09, 2007 at 10:09:35AM -0800, Ian Lance Taylor wrote:
>
> That is not strictly required for LTO as I see it. With LTO, the lto
> program is going to read the .o files with the IL information. It
> will then generate a new .s file to pass to the assembler. The IL
> information will never go through the linker.
>
> Of course, it is also possible that LTO .o files with IL information
> will be passed directly to the linker, for whatever reason. In that
> case, we may want the linker to remove the IL information. This is
> not substantially different from the linker's current ability to strip
> debugging information on request.

It is different since stripping debugging information is controlled
by a linker switch. The new section attribute will make section
to be discarded regardless any linker switch.

>
> So if you want to propose a solution for that, I think you should
> consider how it can be used for debugging information as well. And I
> don't think SHF_DISCARD is a good name. We don't want to arbitrarily
> discard the data, we want to discard it in certain specific scenarios.

It is just a way to make a section to be discarded for executable
and DSO. I am not sure if you want to mark debugging information to
be discarded unless you mean a switch which will ignore the new
attribute so that such debugging information won't be discarded.

You should mark a section with SHF_DISCARD only if such a section
will be removed during final link in all scenarios.

H.J.

[Roland McGrath]

It doesn't seem desireable to me. SHF_ALLOC won't be set on those
sections, and that is enough. It may very well be desireable to have LTO
information available in final objects, just as with debug info.

[Rod Evans]

We invented:

#define SHF_EXCLUDE 0x80000000

a long time ago, which is applied to some sections within relocatable
objects. Sections tagged with this flag are removed from any final
object (executables of .so's).

This probably should have followed a SHF_SUNW_ conversion, but this
was invented long before we thought about OS specific flags.

SHF_EXCLUDE

This section is excluded from input to the link-edit of an executable
or shared object. This flag is ignored if the SHF_ALLOC flag is also
set, or if relocations exist against the section.

--

Rod.

[Lu, Hongjiu]

Hi Rod,

It looks like SHF_EXCLUDE is exactly what I am looking for. How useful
is it in your experiences?

Thanks.

H.J.
hongj...@intel.com

[Rod Evans]

Lu, Hongjiu wrote:

> It looks like SHF_EXCLUDE is exactly what I am looking for. How useful
> is it in your experiences?

As far as I can tell, this was introduced with the SYSTEM V APPLICATION
BINARY INTERFACE for the PowerPC Processor Supplement back in
September 1995 :-)

Then the Fortran folks got a hold of it for adding some specific sections
that they didn't want added to the final output file.

Whether it's being used today by any of our compiler components I don't
know. I'll put some feelers out.

--

Rod.

[Rod Evans]

Our compiler folks tell me that they can create optimization (.annotate)
sections that are used during the compilation process, but are expected
to be excluded from the final executable or shared object, and that these
sections are being tagged SHF_EXCLUDE.

--

Rod.