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

[Seongbae Park]

On 09 Jan 2007 10:09:35 -0800, Ian Lance Taylor <iant@google.com> wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
>
> > 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.
>
> 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.

Not only this isn't a requirement, there's a scenario where
you *want* to keep the IL inside LTO-optimized DSO and executables
for re-optimization.
With LTO and IL inside executables and DSO,
it becomes possible to do profile-collection without any source code
and re-optimize the binary. i.e. an executable can be released with IL inside,
and the user of the binary can choose to do profile collection
on their own input, and re-optimize the binary to squeeze more performance.
This scenario also improves the usability of the profile-feedback directed
optimization (by not requiring the source code access and the whole
build environment for profile feedback optimization).

> 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 should be optional for the linker to remove the sections containing IL.
We probably want to have a new option to strip to remove such sections
as well as linker option to remove such sections.

> 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.
-- 
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com"