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: [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


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