This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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";


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]