Re: [GOLD] Additional linker parameters. Proposal.

[=?big5?b?RG91ZyBLd2FuICjD9q62vHcp?= <dougkwan at google dot com>]

Hi,

Your help is appreciated but I already have some partially working
code.  I had started looking at this problem a few weeks ago but
stopped when I started pushing all the stub generation code.

-Doug

2009/10/26 Viktor Kutuzov <vkutuzov@accesssoftek.com>:
> 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.
>>>
>>
>
>