llvm dev - Mar 2017 - [CLANG BUG] Generate ELF for aarch64-apple-iphoneos

Hi,

I’ve stumbled across something curious with the Relase_40 I have built here:

I tried to build for aarch64-apple-iphoneos, but ended up getting ELF objects

$ clang -target aarch64-apple-iphoneos -c tmp.ll -o tmp.o
warning: overriding the module target triple with aarch64-apple-iphoneos
[-Woverride-module]
1 warning generated.
bin
$ file tmp.o
tmp.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), not stripped

The contents of tmp.ll seems irrelevant, the result can be reproduced with an
empty file.

Result is the same with

clang version 4.0.0 (https://github.com/llvm-mirror/clang.git
559aa046fe3260d8640791f2249d7b0d458b5700) (http://llvm.org/git/llvm.git
3de71b0e7b7a3b5df49f05a4653d4b1ecb70bfab)
Target: x86_64-apple-darwin16.4.0
Thread model: posix

and

Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.4.0
Thread model: posix

The solution seems to be to use arm64-apple-ios as a target, aarch64-apple-ios
however results in:
error: unknown target triple 'unknown-apple-macosx10.4.0', please use
-triple or -arch

How can I obtain a list of supported target triples from clang?

Cheers,
 Moritz

On 12 March 2017 at 08:33, Moritz Angermann via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I tried to build for aarch64-apple-iphoneos, but ended up getting ELF
objects
As you've discovered, "ios" is the way this is spelled. Triples
are in
a bit of a murky area between implementation detail and public
interface.

Clang has to support the commonly used ones (arm-linux-gnueabihf,
x86_64-linux-gnu, ...). But LLVM uses finer distinctions to determine
how it should generate code; for example that first ARM triple might
go through to the backend as "thumbv7-linux-gnueabihf" indicating code
generation for ARMv7 in Thumb mode.

This isn't ideal, and there's very low-level movement towards
improving the situation. But it hasn't come up in a while.
> The solution seems to be to use arm64-apple-ios as a target,
aarch64-apple-ios however results in:
Darwin provides a limited set of named configurations rather than
using triples directly. The canonical way to compile for AArch64 there
is by specifying "-arch arm64" instead of -target.
> How can I obtain a list of supported target triples from clang?
You can't really. There are too many variants with differing degrees of
support.

Cheers.

Tim.

Hi Tim,

thanks for looking into this.
> On Mar 12, 2017, at 11:06 PM, Tim Northover <t.p.northover at
gmail.com> wrote:
> 
> On 12 March 2017 at 08:33, Moritz Angermann via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> I tried to build for aarch64-apple-iphoneos, but ended up getting ELF
objects
> 
> As you've discovered, "ios" is the way this is spelled.
Triples are in
> a bit of a murky area between implementation detail and public
> interface.
> 
> Clang has to support the commonly used ones (arm-linux-gnueabihf,
> x86_64-linux-gnu, ...). But LLVM uses finer distinctions to determine
> how it should generate code; for example that first ARM triple might
> go through to the backend as "thumbv7-linux-gnueabihf" indicating
code
> generation for ARMv7 in Thumb mode.
> 
> This isn't ideal, and there's very low-level movement towards
> improving the situation. But it hasn't come up in a while.
What’s the recommended approach to be taken from llvms point of view?
with -arch and -march? How would I differentiate macosx, ios, watchos then?
What would I set for aarch64-unknown-linux-android instead of the target?
>> The solution seems to be to use arm64-apple-ios as a target,
aarch64-apple-ios however results in:
> 
> Darwin provides a limited set of named configurations rather than
> using triples directly. The canonical way to compile for AArch64 there
> is by specifying "-arch arm64" instead of -target.
Is there some difference between aarch64 and arm64?
> 
>> How can I obtain a list of supported target triples from clang?
> 
> You can't really. There are too many variants with differing degrees of
support.
Thank you. That makes sense! Can I ask clang for the supported architectures
then?

Cheers,
 Moritz