[LLVMbugs] [Bug 15557] New: ARM Triplet support is Debian-specific, Triplet support library is non-flexible
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Wed Mar 20 18:51:26 PDT 2013
http://llvm.org/bugs/show_bug.cgi?id=15557
Bug ID: 15557
Summary: ARM Triplet support is Debian-specific, Triplet
support library is non-flexible
Product: libraries
Version: trunk
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Support Libraries
Assignee: unassignedbugs at nondot.org
Reporter: jonathan at jonmasters.org
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
[ 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.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130321/7ecd2842/attachment.html>
More information about the llvm-bugs
mailing list