[GOLD] Additional linker parameters. Proposal.

[Viktor Kutuzov]

What prevents multiple objects of having contradict to each other attributes and how this is different from having explicit 
parameter?
Up to me, this case should be validated and handled anyway and does not relevant to this discussion.

> You may want to look at elf32-arm.c and elf-attr.c in bfd.

I have looked at that code but I'll do it again. It looks like I'm missing something here.

Thanks.

-Viktor

----- Original Message ----- 
From: Doug Kwan ($Bop?6y~(B)
To: Viktor Kutuzov
Cc: binutils@sourceware.org
Sent: Friday, October 23, 2009 6:40 PM
Subject: Re: [GOLD] Additional linker parameters. Proposal.


The architectural information is stored in the attribute sections of objects. Like Ian said, the right approach is to handle the 
attributes.  It would be disastrous to specify an incorrect architecture in command line that contradicts what is specified in 
attributes.  You may want to look at elf32-arm.c and elf-attr.c in bfd.
-Doug
On Oct 23, 2009 5:11 PM, "Viktor Kutuzov" <vkutuzov@accesssoftek.com> wrote:

Hello everyone,

It is a good idea to be able to explicitly set certain target parameters for gold to perform some relocations (for example 
R_ARM_V4BX) or do some linking time optimizations (see LLVM LTO codegen for more details), especially in the cross-compiling 
environment.

I'd like to add a support for additional gold command line parameters to specify the target (architecture, cpu and such).
Here is the list:

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

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

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

-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.

In the gold, we can place these options to the global static object such as RequestedTargetInfo and use this information everywhere 
we need or want to

* set a reasonable default for output file format if --oformat argument was omitted;
* perform some architecture-specific relocation or optimizations;

These options shell also be passed to plugins. This could be done by extending the existing plugin passing parameters mechanism. I'd 
prefer adding 4 new tag ids like LDPT_TARGET_ARCH, LDPT_TARGET_ATTR, LDPT_TARGET_CPU, and LDPT_TARGET_TRIPLE respectively to plugin 
API and support them in plugin.cc.

If this is fine, I can prepare a patch for review.

Cheers,
Viktor.