[GOLD] Additional linker parameters. Proposal.

[Viktor Kutuzov]

Hi Doug,

I think this is a good idea and will give us a solid default choice.
Please let me know if we could split the work somehow. I'll be glad to get my share. :)

Best regards,
Viktor

----- Original Message ----- 
From: "Doug Kwan (Ãö®¶¼w)" <dougkwan@google.com>
To: "Viktor Kutuzov" <vkutuzov@accesssoftek.com>
Cc: "Ian Lance Taylor" <iant@google.com>; "binutils" <binutils@sourceware.org>
Sent: Saturday, October 24, 2009 12:40 AM
Subject: Re: [GOLD] Additional linker parameters. Proposal.


> Hi Viktor,
>
> I did not have access to the binutils source code when I wrote the
> previous reply.  Now I do and see if I can explain my points a little
> bit better.
>
> In ARM,  ABI information are stored in two places, in the machine
> flags of the ELF header and in the attributes.  You can take a look at
> the ARM ELF specifications (4.2.1 and 4.3.6).  In elf32-arm.c, the
> function elf32_arm_copy_private_bfd_data() handles merging for flags
> in the ELF headers where as the function
> elf32_arm_merge_eabi_attributes() handles the attributes.  These
> functions try to combine flags or attributes if it is meaningful or
> issue warnings or errors if it is not.
>
> Personally,  I would prefer following standard practices for better
> inter-operatability with other tools.  Since gcc, gas and ld all use
> attributes and machine flags to pass ABI information,  doing the same
> in gold makes integrating it into the gnu toolchain easier.  Note that
> object attributes are not ARM only.  They are also used by the PowerPC
> and MIPS at least.  It would be really useful if gold supports object
> attributes in general so that other backends may also benefit.
>
> What do you think?
>
> -Doug
>
> 2009/10/23 Viktor Kutuzov <vkutuzov@accesssoftek.com>:
>> 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 (Ãö®¶¼w)
>> 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.
>>
>