This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [GOLD] Additional linker parameters. Proposal.


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.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]