search

llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
29.17k stars 12.04k forks source link

ARM Triplet support is Debian-specific, Triplet support library is non-flexible #15929

Open llvmbot opened 11 years ago

llvmbot commented 11 years ago
Bugzilla Link 15557
Version trunk
OS Linux
Blocks llvm/llvm-bugzilla-archive#15666
Reporter LLVM Bugzilla Contributor
CC @asl,@compnerd,@jryans

Extended Description

[ Not filed against clang because this is a specific limitation in LLVM core ]

LLVM understands the traditional GNU concept of a Triplet (or Quadriplet):

For example arm-linux-gnueabi. The LLVM Triplet implementation intends to abstract this into a Triple class but unfortunately hard-codes various assumptions about the way these are structured which do not cover all of the deployed use cases. Worse, the current implementation specific to ARM makes very distribution-specific assumptions that Debian (and its derivatives) are in use.

Here is the triplet string encoding used for hardware-floating point enabled versions of the ARM architecture based upon the newest gnueabi:

The above represents the Debian-specific triplet, whereas Fedora uses:

Here, you can see that Debian treat hardware floating point as part of the ABI, whereas Fedora treats the hardware floating point as part of the architecture. There reasonable arguments for either approach, but unfortunately LLVM supports only the former. This is because the precise position of various components of the triplet is magic in the LLVM support library. Many code assumptions exist such that it is not possible to easily separate out and abstract the difference.

I made a half-baked patch that added armv7hl-redhat-linux-gnueabi to the list of ARMHFTriples in tools/clang/lib/Driver/ToolChains.cpp (along with some detection code), but there are many other places that require fixing. I have heard that there is an intention to rework the entire LLVM triplet code, so it will be good to find out what the right course of action here is to De-Debianify LLVM.

llvmbot commented 2 years ago

mentioned in issue llvm/llvm-bugzilla-archive#15666

llvmbot commented 10 years ago

A tweak to fix the incorrect default ARM float ABI detection in Gentoo This simple tweak fixes the default softfp vs. hard floating point ABI selection for the native ARM Clang compiler in Gentoo, where the hardfloat triplet name is armv7a-hardfloat-linux-gnueabi. This basically has about the same effect as passing the -mfloat-abi=hard command line option. The patched part of code is on the fallback path, where it tries to pick a reasonable default in the absence of explicit configuration.

A fully functional crosscompiler (for example, x86-64 -> ARM) may need more work and changes in some other places. Likely the ones mentioned by Jon Masters.

llvmbot commented 11 years ago

Confirmed! many valid GNU triplets are missing, not only for ARM but also for MIPS for example. The central repository for valid GNU triplets are here: http://git.savannah.gnu.org/cgit/config.git

llvmbot commented 3 months ago

@llvm/issue-subscribers-clang-driver

Author: None (llvmbot)

| | | | --- | --- | | Bugzilla Link | [15557](https://llvm.org/bz15557) | | Version | trunk | | OS | Linux | | Blocks | llvm/llvm-bugzilla-archive#15666 | | Reporter | LLVM Bugzilla Contributor | | CC | @asl,@compnerd,@jryans | ## Extended Description [ Not filed against clang because this is a specific limitation in LLVM core ] LLVM understands the traditional GNU concept of a Triplet (or Quadriplet): * `arch-os-abi` * `arch-vendor-os-abi` For example `arm-linux-gnueabi`. The LLVM Triplet implementation intends to abstract this into a Triple class but unfortunately hard-codes various assumptions about the way these are structured which do not cover all of the deployed use cases. Worse, the current implementation specific to ARM makes very distribution-specific assumptions that Debian (and its derivatives) are in use. Here is the triplet string encoding used for hardware-floating point enabled versions of the ARM architecture based upon the newest `gnueabi`: * `arm-linux-gnueabihf` The above represents the Debian-specific triplet, whereas Fedora uses: * `armv7hl-redhat-linux-gnueabi` Here, you can see that Debian treat hardware floating point as part of the ABI, whereas Fedora treats the hardware floating point as part of the architecture. There reasonable arguments for either approach, but unfortunately LLVM supports only the former. This is because the precise position of various components of the triplet is magic in the LLVM support library. Many code assumptions exist such that it is not possible to easily separate out and abstract the difference. I made a half-baked patch that added armv7hl-redhat-linux-gnueabi to the list of `ARMHFTriples` in `tools/clang/lib/Driver/ToolChains.cpp` (along with some detection code), but there are many other places that require fixing. I have heard that there is an intention to rework the entire LLVM triplet code, so it will be good to find out what the right course of action here is to De-Debianify LLVM.