Re: [GOLD] Additional linker parameters. Proposal.

[Ian Lance Taylor <iant at google dot com>]

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