[PATCH][lld] Begin AArch64 support

[Shankar Easwaran]

Hi Tim,
>> The way to test would be :-
>>
>> lld -flavor gnu -target [x86_64|hexagon|x86] ....
> This was what gave me the linker script error, if I'm interpreting you
> correctly:
>
> $ cat simple.s
>          .text
>          .global _start
>          .type _start, at function
> _start:
>          callq bar
>          ret
> $ clang simple.s -c- -o- \
>    | lld -flavor gnu -target x86_64 emit-yaml -r - \
>    | lld -flavor gnu -target x86_64 -
> Failed to read file: -: Error parsing linker script
>
> Everything except that last command is just to get an obviously
> correct YAML file containing (in this case) an R_X86_64_PC32. The idea
> is to make sure that last command can parse "R_X86_64_PC32" as a
> string and knows what to do with it, at least as far as constructing
> an internal representation.
The problem that you are seeing here is because of 
ELFTargetInfo::parseFile interpreting the input file as a script.

ELFTargetInfo, parses the input file using the following

- If the input contains a ELF magic, treat it as ELF file
- If the input ends in extension *objtxt*, treat it as YAML
- otherwise treat it as linker script

In your case the input is being treated as a linker script as, stdin 
based yaml support doesnot exist.

Can you convert the file to .objtxt and use that in the command line.

>> For your case you need to handle aarch64 seperately (see lld-core.cpp).
> To me it looks like Nick Kledzik's refactoring last month made
> lld-core dead code. It's not added in CMakeLists.txt any more.
>
> The replacement (lib/Driver/CoreDriver.cpp) appears to be completely
> target-agnostic. Is that likely just because no-one has got around to
> adding target-specific intelligence to it yet, or is it a design
> decision?
Ah sorry about the wrong comment. The code changes that you would need 
to refer would be
in function ELFTargetInfo::create in file 
lib/ReaderWriter/ELF/ELFTargetInfo.cpp

Thanks

Shankar Easwaran

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130506/cb32f7b6/attachment.html>