llvm dev - Nov 2013 - [LLVMdev] Targeting ARM Cortex-a9 from x86_64 with clang

On Tue, Nov 26, 2013 at 11:44 AM, Renato Golin <renato.golin at
linaro.org>wrote:
> On 26 November 2013 15:36, Rob Stewart <robstewart57 at gmail.com>
wrote:
>
>> $ clang -v -target armv7a-linux-eabi -mcpu=cortex-a9 -mfloat-abi=soft
>> -mfpu=neon helloworld.c
>>
>
> Hi Rod,
>
> You need cross-binutils installed on your box. If you use Debian, there
> are packages (gcc-4.7-arm-linux-gnueabi and friends). Other distros may
> have similar packages, but you can always download the Linaro toolchain (
> http://releases.linaro.org/latest/components/toolchain).
>
> Supposing you already have it, and it's in the PATH, Clang only
recognizes
> it automatically if your triple is identical to the name of your cross
> compiler (See "Toolchain Options" in the referred doc). That
means, you
> either need to have an "armv7a-linux-eabi-gcc" on the path, or
you have to
> change your triple to something like "arm-linux-gnueabi", because
that's
> what your cross-GCC will probably be called. The -mcpu will take care of
> choosing v7A.
>
> Otherwise, you'll have to set --sysroot or --gcc-name as well as the
> triple, but that's not recommended.
>
>
>  "/usr/bin/as" -mfpu=neon -mfloat-abi=soft -mcpu=cortex-a9
-mfpu=neon
>>
>
> As you can see, it chose the platform assembler, which is x86_64-only, not
> a cross-assembler. That's the hint that Clang didn't find your
> cross-binutils.
>
Out of curiosity, can't clang do the assembly itself in this case?

>
> I know, Clang could have better error detection and stop when it's
clearly
> the wrong architecture, but hey, Clang can deal with all archs on the same
> binary, there's no reason your system assembler (whatever it is)
can't,
> too. One day, LLVM binutils will be... ;)
>
Well, just remember that the GNU binutils that those tools are derived from
support far more architectures (3x, 5x?) than LLVM does (just supporting
linux requires like 30 architectures). When we get to that point, it will
probably not make sense for a distro to ship a binary targeting all the
architectures that we support, for the same reason it doesn't make sense
for them to install binaries for every target supported by the GNU
toolchain. (but at least in LLVM's case, it would be a conscious tradeoff,
while IIRC the GNU toolchain simply can't be built in a way that targets
all of them from a single binary).

-- Sean Silva

>
> cheers,
> --renato
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131126/70ea0853/attachment.html>

On 26 November 2013 17:40, Sean Silva <chisophugis at gmail.com> wrote:
> As you can see, it chose the platform assembler, which is x86_64-only, not
>> a cross-assembler. That's the hint that Clang didn't find your
>> cross-binutils.
>>
>
> Out of curiosity, can't clang do the assembly itself in this case?
>
It can, but you need to use -integrated-as, because that's not the default
yet. (some missing features).


(but at least in LLVM's case, it would be a conscious tradeoff, while
IIRC
> the GNU toolchain simply can't be built in a way that targets all of
them
> from a single binary).
>
Exactly!

I only build the ARM back-end on my bots because I don't really care for
the rest, but I know I can, if I really want to.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131126/dad137f1/attachment.html>

> Out of curiosity, can't clang do the assembly itself in this case?
Integrated-assembler is still disabled by default on ARM ELF. It
really should be enabled now, in my opinion. Of course, you'd still
need the linker so dependencies wouldn't change noticeably.

Cheers.

Tim.

>> Out of curiosity, can't clang do the assembly itself in this case?
>
> It can, but you need to use -integrated-as, because that's not the
default
> yet. (some missing features).
Do you remember what those features are Renato? MC has been around
years, we really should start sorting them now.

Cheers.

Tim

On Tue, Nov 26, 2013 at 12:40:17PM -0500, Sean Silva
wrote:
> Well, just remember that the GNU binutils that those tools are derived from
> support far more architectures (3x, 5x?) than LLVM does (just supporting
> linux requires like 30 architectures). When we get to that point, it will
> probably not make sense for a distro to ship a binary targeting all the
> architectures that we support, for the same reason it doesn't make
sense
> for them to install binaries for every target supported by the GNU
> toolchain.
I know that FreeBSD limits the set of targets by default mostly for
compile reasons, the size difference is not that big. The trade off is
*much* better with LLVM.

Joerg

On 26 Nov 2013, at 19:10, Joerg Sonnenberger <joerg at britannica.bec.de>
wrote:
> On Tue, Nov 26, 2013 at 12:40:17PM -0500, Sean Silva wrote:
>> Well, just remember that the GNU binutils that those tools are derived
from
>> support far more architectures (3x, 5x?) than LLVM does (just
supporting
>> linux requires like 30 architectures). When we get to that point, it
will
>> probably not make sense for a distro to ship a binary targeting all the
>> architectures that we support, for the same reason it doesn't make
sense
>> for them to install binaries for every target supported by the GNU
>> toolchain.
> 
> I know that FreeBSD limits the set of targets by default mostly for
> compile reasons, the size difference is not that big. The trade off is
> *much* better with LLVM.
We only do it, I believe, for the bootstrap build.  When you build FreeBSD, you
first build the toolchain that you'll build the system with (from the source
tree that you're going to build, for the host arch), then you build the tree
with that toolchain (for whatever your target arch is).  Given how much of the
total build time LLVM / Clang accounts for, building it twice caused a lot of
irritating.  We quite aggressively stripped down the bootstrap build, so that it
only supports the specified target (unless requested otherwise), doesn't
include the Clang rewriter, the static analyser, and a few other things. 
Removing the JIT would probably also make sense.

David