[GOLD] Additional linker parameters. Proposal.

[Viktor Kutuzov]

Hello Ian,

> When I think of link time optimization, I think of a compiler
> operation.  gold generates very little code, currently just PLT
> entries and ARM stubs as far as I know.  It may be that we need
> options to control this code, but I would have to be convinced.

This looks like a disconnection point.
You think that link time optimization does not involve code generation or a very little.
I think that link time optimization does involve code generation and will involve more and more of it while more advance 
optimizations will be added.
The code generation itself happens outside of the gold and gold itself could generate very little code, but gold plug-ins will, and 
we should be able to accept and deliver the accurate target information down through the whole tool chain.

Here is a real example

LLVM is one of the gold user.
They generate an intermediate platform independent bitcode  at the compilation time. Then they use a gold plug-in to do LTO. At the 
link time they resolve all symbols, then run optimizations and then, at the end when it gets actually requested, generate a native 
object code.
You can find more details here http://llvm.org/docs/LinkTimeOptimization.html.

Viktor

----- Original Message ----- 
From: "Ian Lance Taylor" <iant@google.com>
To: "Viktor Kutuzov" <vkutuzov@accesssoftek.com>
Cc: <binutils@sourceware.org>
Sent: Tuesday, October 27, 2009 8:07 AM
Subject: Re: [GOLD] Additional linker parameters. Proposal.


Viktor Kutuzov <vkutuzov@accesssoftek.com> writes:

> Consider multiple input files with different target architectures
> (backward compatibile). In this case the result will depend on the
> order in which input files are listed in the argumeent list.

I don't see why.  It seems to me that the output architecture should
be the most restrictive subset of the input architectures.


> The default is a good, but it would be even better to be able to say
> explicitly what target architecture is expected as the result.

When would one want to do that in practice?  Is this a role which
could be better performed by a tool like objcopy?


> This options doesn't add any complexity sinse the check of input
> objects for bad combinations is there anyway.

All options add complexity, by definition.  The goal should be to
provide all options that are required but none that are not.  (gold
has an additional goal of being more or less compatible with the GNU
linker; many options exist solely for that purpose.)


> But it adds some value. This especially important if we think about
> linking time optimization, when some code generation is involved at
> the linking stage.

When I think of link time optimization, I think of a compiler
operation.  gold generates very little code, currently just PLT
entries and ARM stubs as far as I know.  It may be that we need
options to control this code, but I would have to be convinced.

Ian