Re: [GOLD] Additional linker parameters. Proposal.

[Viktor Kutuzov <vkutuzov at accesssoftek dot 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.