Re: [GOLD] Additional linker parameters. Proposal.

[Viktor Kutuzov <vkutuzov at accesssoftek dot com>]

Thanks everyone for the good discussion.

I see that I had to explain the idea better in my original e-mail. :)
Let's discuss this per option, just to keep the discussion under control.

> > -march=<string> - to specify the target architecture (instruction set). For example: -march=armv7a.
>
> This kind of information is generally already available in the input
> files.  For example, ARM EABI supports various tags.  It seems like
> the right approach here is for the linker to read those tags and use
> them to make any relevant decisions.

Yes, it will be available there after that patch Doug has mentioned. And I think this is a very good idea. Especially if all 
backends will support this or it will be handled on some platform-independent manner.
This gives a good default choise. However, this does not resolve the issue, at least as I see it. Let me explain.
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.
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.

This options doesn't add any complexity sinse the check of input objects for bad combinations is there anyway.
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.

Does this make sense?

Viktor

----- Original Message ----- 
From: "Ian Lance Taylor" <iant@google.com>
To: "Viktor Kutuzov" <vkutuzov@accesssoftek.com>
Cc: <binutils@sourceware.org>
Sent: Friday, October 23, 2009 6:21 PM
Subject: Re: [GOLD] Additional linker parameters. Proposal.


Viktor Kutuzov <vkutuzov@accesssoftek.com> writes:

> -mtriple=<string> - to provide overrode target triple for module. For example: -mtriple=arm-apple-darwin.

The GNU linker already supports a -m option, which sets the so-called
"emulation".  So gold should not introduce new options starting with
-m which are incompatible.  It would be OK if the proposed options
required a double dash.

One problem that the GNU linker has a confusing set of notions about
how to specify the output format.  The GNU linker permits you to
specify an input file target via -b or TARGET in a linker script or
GNUTARGET in the environment; this is a string like elf32-i386 or
elf64-x86-64.  It permits you to specify an output file target via
--oformat or OUTPUT_FORMAT in a linker script.  It permits you to
specify an emulation via -m or LDEMULATION in the environment; this is
a string like elf_i386 or elf_x86_64.  Not many people understand the
differences between them.  They were introduced for good reasons, but
the result is confusing.

For compatibility purposes gold is required to support the -b and
--oformat options.  It accepts and ignores the -m option.  In general,
gold tries to produce the output based on the input files.  That is,
if the input files are in a particular format, gold will produce that
format on output.

This is all a long-winded way of saying: what's the point of this
option?  When would it be used?  What problem does it solve, and why
is a linker option the right way to solve that problem?

Programmers almost never want to think about the linker.  Any time
they are forced to think about the linker it is to overcome some sort
of toolchain deficiency.  As much as possible, the goal should be to
avoid deficiencies by default, not to provide options for them.


> -march=<string> - to specify the target architecture (instruction set). For example: -march=armv7a.

This kind of information is generally already available in the input
files.  For example, ARM EABI supports various tags.  It seems like
the right approach here is for the linker to read those tags and use
them to make any relevant decisions.


> -mcpu=<cpu-name> - to provide a target cpu name for result code.  For example: - mcpu=Cortex-A9

Same here.


> -mattr=<a1,+a2,-a3,...> - to override or control specific attributes
> of the target, such as whether SIMD operations are enabled or not. The
> default set of attributes is set by the current CPU. For example:
> mattr=neon for ARM Neon codegen.

Why would gold ever need to know whether SIMD operations are enabled?

I do agree that there is likely to be a need for target specific
command line options, and it would be good if those could be handled
in some sort of common framework.


I very much do not want to introduce functionality of this sort in
advance of a demonstrated need for this functionality.  It's very easy
to overdesign this sort of thing.

Ian