Re: [GOLD] Additional linker parameters. Proposal.

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

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