Re: Triplet for ARM Linux HardFP ABI, again
On 21/02/11 10:12, Guillem Jover wrote: This was already discussed in this list some time ago [0]. But it came up again when restarting the discussion for the proposed new armhf port for Debian. [0]http://gcc.gnu.org/ml/gcc/2010-07/msg00179.html My arguments for why a distinct triplet is needed can be found in [1], it's a big long though. Most of the points there revolve around the fact that we rely on the toolchains as configured by_default_ to produce the expected output targetting a concrete architecture, it also has implications for the file system paths. [1]http://lists.debian.org/debian-dpkg/2011/02/msg00039.html It seems from reading the past discussion on this list that the main objection was that the triplet should not be used to decide what floating point ABI to use in gcc. No problem with that! Up front, let me say I disagree with the previous finding that the triplet isn't the right place for this kind of thing. It's clear to me that there's plenty of prior art here, and it would work for us very nicely, thank you very much. That said, there are down-sides to target-triplets (not least that once you've chosen one, you find yourself stuck with it for backward compatibility, even after it makes no sense any more), and many people seem to believe it would be better if they had never been invented, so . I fail to see how abusing the OS/ABI field is any better than abusing the vendor field? The patch you posted is surely just the tip of the iceberg - there are thousands of packages in Debian, and any one of them might need adjustment to cope with this change. When I proposed a new triplet before, in the thread you referenced above, I proposed having an 'official' name that everyone would agree on. That would have been disruptive. Your triplet would be unofficial, so I would say it would be hard to justify all that disruption. In the worst case, third parties would start to use your unofficial triplet inconditionally, and would need fixing up to work with anything that is not Debian. In July's thread, it was decided (sort of) that the compiler should not choose its (micro-)configuration based on the triplet. I didn't really agree with that, but there it is. You've decided to stick with that, and have the triplet influence only your build-system. Surely that's exactly what the 'vendor' field is for? It seems like (it has to be) a vendor-specific configuration to me. Adjusting the vendor field should not break any of those thousands of packages (although, no doubt there'll be the odd one or two). It will give you your differentiated pathnames. It will tell your build-system what to do. Why do it the hard way if there is no advantage? Andrew
Re: Triplet for ARM Linux HardFP ABI, again
Here is an amended patch that handles Ada as EABI-only on ARM.
Are there any other comments on the appropriateness of this globbing change?
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff --git a/configure b/configure
index 501c6ff..43ff04f 100755
--- a/configure
+++ b/configure
@@ -3236,7 +3236,7 @@ case ${target} in
noconfigdirs=$noconfigdirs target-libffi target-qthreads
libgloss_dir=arm
;;
- arm*-*-linux-gnueabi)
+ arm*-*-linux-*eabi*)
noconfigdirs=$noconfigdirs target-qthreads
case ${with_newlib} in
no) noconfigdirs=$noconfigdirs target-newlib target-libgloss
diff --git a/configure.ac b/configure.ac
index 9121d65..e1a42e0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -682,7 +682,7 @@ case ${target} in
noconfigdirs=$noconfigdirs target-libffi target-qthreads
libgloss_dir=arm
;;
- arm*-*-linux-gnueabi)
+ arm*-*-linux-*eabi*)
noconfigdirs=$noconfigdirs target-qthreads
case ${with_newlib} in
no) noconfigdirs=$noconfigdirs target-newlib target-libgloss
diff --git a/gcc/ada/gcc-interface/Makefile.in
b/gcc/ada/gcc-interface/Makefile.in
index b64ba55..7559efb 100644
--- a/gcc/ada/gcc-interface/Makefile.in
+++ b/gcc/ada/gcc-interface/Makefile.in
@@ -1841,7 +1841,7 @@ ifeq ($(strip $(filter-out powerpc% linux%,$(arch)
$(osys))),)
LIBRARY_VERSION := $(LIB_VERSION)
endif
-ifeq ($(strip $(filter-out arm% linux-gnueabi,$(arch) $(osys)-$(word
4,$(targ,)
+ifeq ($(strip $(filter-out arm% linux-%eabi%,$(arch) $(osys))),)
LIBGNAT_TARGET_PAIRS = \
a-intnam.adsa-intnam-linux.ads \
s-inmaop.adbs-inmaop-posix.adb \
diff --git a/gcc/config.gcc b/gcc/config.gcc
index d1baea0..e748188 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -822,13 +822,13 @@ arm*-*-linux*)# ARM GNU/Linux with ELF
esac
tmake_file=${tmake_file} t-linux arm/t-arm
case ${target} in
- arm*-*-linux-*eabi)
+ arm*-*-linux-*eabi*)
tm_file=$tm_file arm/bpabi.h arm/linux-eabi.h
tm_file=$tm_file ../../libgcc/config/arm/bpabi-lib.h
tmake_file=$tmake_file arm/t-arm-elf arm/t-bpabi arm/t-linux-eabi
t-slibgcc-libgcc
# Define multilib configuration for arm-linux-androideabi.
case ${target} in
- *-androideabi)
+ *-androideabi*)
tmake_file=$tmake_file arm/t-linux-androideabi
;;
esac
@@ -850,7 +850,7 @@ arm*-*-uclinux*)# ARM ucLinux
tm_file=dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/linux-gas.h
arm/uclinux-elf.h glibc-stdint.h
tmake_file=arm/t-arm arm/t-arm-elf
case ${target} in
- arm*-*-uclinux*eabi)
+ arm*-*-uclinux*eabi*)
tm_file=$tm_file arm/bpabi.h arm/uclinux-eabi.h
tm_file=$tm_file ../../libgcc/config/arm/bpabi-lib.h
tmake_file=$tmake_file arm/t-bpabi
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 36cab54..81742a1 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3235,7 +3235,7 @@ proc check_effective_target_sync_int_long { } {
|| [istarget i?86-*-*]
|| [istarget x86_64-*-*]
|| [istarget alpha*-*-*]
-|| [istarget arm*-*-linux-gnueabi]
+|| [istarget arm*-*-linux-*eabi*]
|| [istarget bfin*-*linux*]
|| [istarget hppa*-*linux*]
|| [istarget s390*-*-*]
@@ -3266,7 +3266,7 @@ proc check_effective_target_sync_char_short { } {
|| [istarget i?86-*-*]
|| [istarget x86_64-*-*]
|| [istarget alpha*-*-*]
-|| [istarget arm*-*-linux-gnueabi]
+|| [istarget arm*-*-linux-*eabi*]
|| [istarget hppa*-*linux*]
|| [istarget s390*-*-*]
|| [istarget powerpc*-*-*]
diff --git a/libjava/configure b/libjava/configure
index f79e53b..47e3f23 100755
--- a/libjava/configure
+++ b/libjava/configure
@@ -20527,7 +20527,7 @@ case ${host} in
# on Darwin -single_module speeds up loading of the dynamic libraries.
extra_ldflags_libjava=-Wl,-single_module
;;
-arm*linux*eabi)
+arm*-*-linux-*eabi*)
# Some of the ARM unwinder code is actually in libstdc++. We
# could in principle replicate it in libgcj, but it's better to
# have a dependency on libstdc++.
diff --git a/libjava/configure.ac b/libjava/configure.ac
index 8187eec..b59abb3 100644
--- a/libjava/configure.ac
+++ b/libjava/configure.ac
@@ -919,7 +919,7 @@ case ${host} in
# on Darwin -single_module speeds up loading of the dynamic libraries.
Re: Triplet for ARM Linux HardFP ABI, again
Hi! On Mon, 2011-02-28 at 16:12:32 -0800, Steve Langasek wrote: Here is an amended patch that handles Ada as EABI-only on ARM. diff --git a/gcc/ada/gcc-interface/Makefile.in b/gcc/ada/gcc-interface/Makefile.in index b64ba55..7559efb 100644 --- a/gcc/ada/gcc-interface/Makefile.in +++ b/gcc/ada/gcc-interface/Makefile.in @@ -1841,7 +1841,7 @@ ifeq ($(strip $(filter-out powerpc% linux%,$(arch) $(osys))),) LIBRARY_VERSION := $(LIB_VERSION) endif -ifeq ($(strip $(filter-out arm% linux-gnueabi,$(arch) $(osys)-$(word 4,$(targ,) +ifeq ($(strip $(filter-out arm% linux-%eabi%,$(arch) $(osys))),) LIBGNAT_TARGET_PAIRS = \ a-intnam.adsa-intnam-linux.ads \ s-inmaop.adbs-inmaop-posix.adb \ Actually this should not work, %-patterns only recognize one '%'. That's one of the reasons I just switched to linux%, it was the easy way out. :) thanks, guillem
Re: Triplet for ARM Linux HardFP ABI, again
Guillem Jover writes: On Mon, 2011-02-21 at 17:59:06 +, Joseph S. Myers wrote: On Mon, 21 Feb 2011, Guillem Jover wrote: if you'd consider accepting something ressembling the attached patch A pre-existing condition, but in general where the code you're changing hardcodes gnu that's wrong - arm*-*-linux-uclibceabi is also meant to be valid. So if you allow a suffix here, the general form to accept consistently would be arm*-*-linux-*eabi*. Ok, so something like the attached then (again completely untested)? I've changed the ada part to just match on arm% linux% in the same way the other targets do, as there didn't seem anything GNU EABI specific in commit 8f0372dd2b828c0a0ee05dee4496a021da9cee40 (r155808). Incorrect, the ARM Ada support (which I contributed) is emphatically only for linux-gnueabi. Ada on OABI is known to have non-trivial problems (or did last time I bootstrapped it before gcc-4.4), so that combination is unsupported. Besides, OABI is obsolete.
Re: Triplet for ARM Linux HardFP ABI, again
On Mon, 21 Feb 2011, Guillem Jover wrote: if you'd consider accepting something ressembling the attached patch A pre-existing condition, but in general where the code you're changing hardcodes gnu that's wrong - arm*-*-linux-uclibceabi is also meant to be valid. So if you allow a suffix here, the general form to accept consistently would be arm*-*-linux-*eabi*. -- Joseph S. Myers jos...@codesourcery.com
Re: Triplet for ARM Linux HardFP ABI, again
On Mon, 2011-02-21 at 17:59:06 +, Joseph S. Myers wrote:
On Mon, 21 Feb 2011, Guillem Jover wrote:
if you'd consider accepting something ressembling the attached patch
A pre-existing condition, but in general where the code you're changing
hardcodes gnu that's wrong - arm*-*-linux-uclibceabi is also meant to be
valid. So if you allow a suffix here, the general form to accept
consistently would be arm*-*-linux-*eabi*.
Ok, so something like the attached then (again completely untested)?
I've changed the ada part to just match on arm% linux% in the same way
the other targets do, as there didn't seem anything GNU EABI specific
in commit 8f0372dd2b828c0a0ee05dee4496a021da9cee40 (r155808).
And should probably not be touching the uclinux match.
thanks,
guillem
diff --git a/configure b/configure
index 501c6ff..43ff04f 100755
--- a/configure
+++ b/configure
@@ -3236,7 +3236,7 @@ case ${target} in
noconfigdirs=$noconfigdirs target-libffi target-qthreads
libgloss_dir=arm
;;
- arm*-*-linux-gnueabi)
+ arm*-*-linux-*eabi*)
noconfigdirs=$noconfigdirs target-qthreads
case ${with_newlib} in
no) noconfigdirs=$noconfigdirs target-newlib target-libgloss
diff --git a/configure.ac b/configure.ac
index 9121d65..e1a42e0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -682,7 +682,7 @@ case ${target} in
noconfigdirs=$noconfigdirs target-libffi target-qthreads
libgloss_dir=arm
;;
- arm*-*-linux-gnueabi)
+ arm*-*-linux-*eabi*)
noconfigdirs=$noconfigdirs target-qthreads
case ${with_newlib} in
no) noconfigdirs=$noconfigdirs target-newlib target-libgloss
diff --git a/gcc/ada/gcc-interface/Makefile.in b/gcc/ada/gcc-interface/Makefile.in
index b64ba55..cbe6b70 100644
--- a/gcc/ada/gcc-interface/Makefile.in
+++ b/gcc/ada/gcc-interface/Makefile.in
@@ -1841,7 +1841,7 @@ ifeq ($(strip $(filter-out powerpc% linux%,$(arch) $(osys))),)
LIBRARY_VERSION := $(LIB_VERSION)
endif
-ifeq ($(strip $(filter-out arm% linux-gnueabi,$(arch) $(osys)-$(word 4,$(targ,)
+ifeq ($(strip $(filter-out arm% linux%,$(arch) $(osys))),)
LIBGNAT_TARGET_PAIRS = \
a-intnam.adsa-intnam-linux.ads \
s-inmaop.adbs-inmaop-posix.adb \
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 54b822e..1a47343 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -820,13 +820,13 @@ arm*-*-linux*) # ARM GNU/Linux with ELF
esac
tmake_file=${tmake_file} t-linux arm/t-arm
case ${target} in
- arm*-*-linux-*eabi)
+ arm*-*-linux-*eabi*)
tm_file=$tm_file arm/bpabi.h arm/linux-eabi.h
tm_file=$tm_file ../../libgcc/config/arm/bpabi-lib.h
tmake_file=$tmake_file arm/t-arm-elf arm/t-bpabi arm/t-linux-eabi t-slibgcc-libgcc
# Define multilib configuration for arm-linux-androideabi.
case ${target} in
- *-androideabi)
+ *-androideabi*)
tmake_file=$tmake_file arm/t-linux-androideabi
;;
esac
@@ -848,7 +848,7 @@ arm*-*-uclinux*) # ARM ucLinux
tm_file=dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/linux-gas.h arm/uclinux-elf.h glibc-stdint.h
tmake_file=arm/t-arm arm/t-arm-elf
case ${target} in
- arm*-*-uclinux*eabi)
+ arm*-*-uclinux*eabi*)
tm_file=$tm_file arm/bpabi.h arm/uclinux-eabi.h
tm_file=$tm_file ../../libgcc/config/arm/bpabi-lib.h
tmake_file=$tmake_file arm/t-bpabi
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 02cb7ac..885c0e0 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3219,7 +3219,7 @@ proc check_effective_target_sync_int_long { } {
|| [istarget i?86-*-*]
|| [istarget x86_64-*-*]
|| [istarget alpha*-*-*]
- || [istarget arm*-*-linux-gnueabi]
+ || [istarget arm*-*-linux-*eabi*]
|| [istarget bfin*-*linux*]
|| [istarget hppa*-*linux*]
|| [istarget s390*-*-*]
@@ -3250,7 +3250,7 @@ proc check_effective_target_sync_char_short { } {
|| [istarget i?86-*-*]
|| [istarget x86_64-*-*]
|| [istarget alpha*-*-*]
- || [istarget arm*-*-linux-gnueabi]
+ || [istarget arm*-*-linux-*eabi*]
|| [istarget hppa*-*linux*]
|| [istarget s390*-*-*]
|| [istarget powerpc*-*-*]
diff --git a/libjava/configure b/libjava/configure
index f79e53b..47e3f23 100755
--- a/libjava/configure
+++ b/libjava/configure
@@ -20527,7 +20527,7 @@ case ${host} in
# on Darwin -single_module speeds up loading of the dynamic libraries.
extra_ldflags_libjava=-Wl,-single_module
;;
-arm*linux*eabi)
+arm*-*-linux-*eabi*)
# Some of the ARM unwinder code is actually in libstdc++. We
# could in principle replicate it in libgcj, but it's better to
# have a dependency on libstdc++.
diff --git a/libjava/configure.ac b/libjava/configure.ac
index 8187eec..b59abb3 100644
--- a/libjava/configure.ac
+++ b/libjava/configure.ac
@@ -919,7 +919,7 @@ case ${host} in
# on Darwin -single_module speeds up loading of the dynamic libraries.
Re: Triplet for ARM Linux HardFP ABI
On 12/07/10 14:25, Andrew Stubbs wrote: This means that we need to choose a name for it. Obviously, it's better if it's an official name, so I want to discuss it here. I'm aware that there is some bikeshedding to do here, but it's better it gets done before anybody gets stuck with something else. There are, of course, some real practical reasons why one name might be better than another. So, it seems this issue is not as simple as I thought. :( Opinion seem to be somewhat divided, but in the absence of any sort of consensus, I suppose I'll have to propose that the various projects use the vendor field. The alternative would be to add a configure test that checked the defaults in the existing host compiler, and duplicated the defaults somehow, but that sounds somewhat icky. Andrew
Re: Triplet for ARM Linux HardFP ABI
Quoting Andrew Stubbs a...@codesourcery.com: Hi All, Hi, long time no see... So here are my suggestions: arm-linux-gnueabihf or maybe arm-linux-gnueabi-hf I don't like the inflation of dashes - it breaks scripts that want to parse the host triplet / quadruplet (IMO having a quadruplets was already a step in the wrong direction) how about using an underscore instead to distinguish separate pieces of the OS/ABI: arm-linux-gnueabi_hf arm-linux-gnuhfeabi or arm-linux-gnu_hf_eabi if we could turn back the clock, I'd even prefer arm-linux_gnu_hf_eabi to get back to a single '-'-parsed OS string, but the linux-gnu stuff is now entrenched, so trying to change back would only cause more disruption.
Re: Triplet for ARM Linux HardFP ABI
On Mon, 2010-07-12 at 10:23 -0400, Joern Rennecke wrote: Quoting Andrew Stubbs a...@codesourcery.com: Hi All, Hi, long time no see... So here are my suggestions: arm-linux-gnueabihf or maybe arm-linux-gnueabi-hf I don't like the inflation of dashes - it breaks scripts that want to parse the host triplet / quadruplet (IMO having a quadruplets was already a step in the wrong direction) how about using an underscore instead to distinguish separate pieces of the OS/ABI: arm-linux-gnueabi_hf arm-linux-gnuhfeabi or arm-linux-gnu_hf_eabi if we could turn back the clock, I'd even prefer arm-linux_gnu_hf_eabi to get back to a single '-'-parsed OS string, but the linux-gnu stuff is now entrenched, so trying to change back would only cause more disruption. quadruplets, quintuplets and even sextuplets wouldn't be a problem if all the preceding parts were compulsory. The problem is that the vendor field is optional, so now arm-linux-gnueabi is ambiguous. Is that a quadruplet that's missed out the vendor part, or a triplet? R.
Re: Triplet for ARM Linux HardFP ABI
Both Linaro and Debian are considering supporting the ARM hard-float variant of the EABI, at least as an unofficial port. This ABI is not compatible with the gnueabi currently in use for most ARM Linux distros, but has a number of performance advantages. This means that we need to choose a name for it. I don't think we do. IMO there's no reason (other than dpkg lameness) why soft-float and hard-float toolchains should have a different target triplet. You can (and people do) already build a hard-float toolchain by specifying --with-float=hard. Anything that rely on the that relies on the target triplet to determine hard v.s. soft-float ABI is fundamentally broken. In a restricted environment (e.g. Debian package builds) you may have a fixed mapping, and even that's liable to fall apart in a multiarch environment. Given you're already making vendor specific assumptions, it seems reasomablt to determing the ABI by vendor-specific means. Of course the real solution if to make the check independent of the triplet. GCC doesn't currently define a preprocessor symbol for the ABI, but that's a separate bug. Obviously, it's better if it's an official name, so I want to discuss it here. I'm aware that there is some bikeshedding to do here, but it's better it gets done before anybody gets stuck with something else. There are, of course, some real practical reasons why one name might be better than another. So here are my suggestions: arm-linux-gnueabihf or maybe arm-linux-gnueabi-hf These will match any package that uses arm*-*-linux-gnueabi*. Choosing which variant is mainly a matter of taste. arm-linux-gnuhfeabi These will match any package that uses arm*-*-linux-*eabi (as I see gcc itself does). I'm not sure which is better. I suspect that, either way, a lot of things will need to be fixed up. I think hf is wrong. This is specifically the vfp EABI supplement. In principle we should allow for other ABI variants (e.g. FPA, Maverick). An alternative would be to use the vendor field. That would be less difficult, but it feels like something of a hack to me. This would be my preferred solution. When all said an done this *is* a hack round a deficiency in your build system. I'm reluctant to propagate that into gcc. It's worth noting that a while ago we made the deliberate decision to start ignoring the cpu field. Previously configuring for xscale-elf would do magical things. Also notice that blindly configuring for armeb-linux-eabi still gives you a little-endian toolchain. Paul
Re: Triplet for ARM Linux HardFP ABI
On Mon, 2010-07-12 at 16:03 +0100, Paul Brook wrote: Both Linaro and Debian are considering supporting the ARM hard-float variant of the EABI, at least as an unofficial port. This ABI is not compatible with the gnueabi currently in use for most ARM Linux distros, but has a number of performance advantages. This means that we need to choose a name for it. I don't think we do. IMO there's no reason (other than dpkg lameness) why soft-float and hard-float toolchains should have a different target triplet. You can (and people do) already build a hard-float toolchain by specifying --with-float=hard. The reason why a new triplet is required is that config.guess needs to generate it when running native. Config.guess is the only way to communicate the information needed for a native compiler when no other information is communicated on the command line, and it only reports a triplet. Yet it's essential that the right ABI gets selected in this case, or you'll have a non-functional toolchain. That is, on a native machine .../configure --prefix=... must build a native compiler that conforms to the native ABI of the machine. Anything that rely on the that relies on the target triplet to determine hard v.s. soft-float ABI is fundamentally broken. In a restricted environment (e.g. Debian package builds) you may have a fixed mapping, and even that's liable to fall apart in a multiarch environment. Given you're already making vendor specific assumptions, it seems reasomablt to determing the ABI by vendor-specific means. Of course the real solution if to make the check independent of the triplet. GCC doesn't currently define a preprocessor symbol for the ABI, but that's a separate bug. Indeed. The draft ACLE specification has one __ARM_PCS_VFP, but that document hasn't been published yet. Obviously, it's better if it's an official name, so I want to discuss it here. I'm aware that there is some bikeshedding to do here, but it's better it gets done before anybody gets stuck with something else. There are, of course, some real practical reasons why one name might be better than another. So here are my suggestions: arm-linux-gnueabihf or maybe arm-linux-gnueabi-hf These will match any package that uses arm*-*-linux-gnueabi*. Choosing which variant is mainly a matter of taste. arm-linux-gnuhfeabi These will match any package that uses arm*-*-linux-*eabi (as I see gcc itself does). I'm not sure which is better. I suspect that, either way, a lot of things will need to be fixed up. I think hf is wrong. This is specifically the vfp EABI supplement. In principle we should allow for other ABI variants (e.g. FPA, Maverick). FPA isn't legal in the EABI. Maverick is incompatible with the Hard-float variant. I accept your point, however, that maybe this should be conveyed more clearly in the name, but in reality, VFP is now *the* way to do hardware floating point on ARM. An alternative would be to use the vendor field. That would be less difficult, but it feels like something of a hack to me. This would be my preferred solution. When all said an done this *is* a hack round a deficiency in your build system. I'm reluctant to propagate that into gcc. FWIW, I can't say I like the idea of using the vendor field for this, but I don't have a particularly strong opinion on that matter. It is true that the vendor field in the triplet is essentially useless today for Linux; but I'm not (yet) convinced that (ab)using it for ABI variant information is the right way to go. It's worth noting that a while ago we made the deliberate decision to start ignoring the cpu field. Previously configuring for xscale-elf would do magical things. Also notice that blindly configuring for armeb-linux-eabi still gives you a little-endian toolchain. The change, I think, was to stop magically changing the ABI rules based on the CPU name, not to ignore it completely: I'd expect xscale to cause v5 code to be generated (unless specifically overridden with --with-cpu). R.
Re: Triplet for ARM Linux HardFP ABI
On 12/07/10 15:51, Richard Earnshaw wrote: if we could turn back the clock, I'd even prefer arm-linux_gnu_hf_eabi to get back to a single '-'-parsed OS string, but the linux-gnu stuff is now entrenched, so trying to change back would only cause more disruption. quadruplets, quintuplets and even sextuplets wouldn't be a problem if all the preceding parts were compulsory. The problem is that the vendor field is optional, so now arm-linux-gnueabi is ambiguous. Is that a quadruplet that's missed out the vendor part, or a triplet? Right, hence arm-none-linux-gnueabi. I forgot about that, but I'm only really talking about the OS part here anyway. Andrew
Re: Triplet for ARM Linux HardFP ABI
.../configure --prefix=... must build a native compiler that conforms to the native ABI of the machine. By my reading at least ppc, mips and sparc allow the default ABI to be changed via --with-float, but none of them have a separate target triplet for this purpose. It's worth noting that a while ago we made the deliberate decision to start ignoring the cpu field. Previously configuring for xscale-elf would do magical things. Also notice that blindly configuring for armeb-linux-eabi still gives you a little-endian toolchain. The change, I think, was to stop magically changing the ABI rules based on the CPU name, not to ignore it completely: I'd expect xscale to cause v5 code to be generated (unless specifically overridden with --with-cpu). It does not. Part of the problem here is whether you want to default to the system you're running on, or the hardware you're running on. Unfortunately config.guess returns the latter, so obeying the cpu name effectively makes us default to --with-arch=native. Paul
Re: Triplet for ARM Linux HardFP ABI
Richard Earnshaw wrote: The reason why a new triplet is required is that config.guess needs to generate it when running native. Config.guess is the only way to communicate the information needed for a native compiler when no other information is communicated on the command line, and it only reports a triplet. Why not fix this? For example, it could also give back configure options (--with-float=hard) that should be implicitly assumed to have been provided. It really does seem like a hack to use triplets in this way; I think Paul's point that anything that depends on the toolchain triplet to determine ABI is inherently busted is pretty persuasive. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Triplet for ARM Linux HardFP ABI
On Mon, 2010-07-12 at 09:19 -0700, Mark Mitchell wrote: Richard Earnshaw wrote: The reason why a new triplet is required is that config.guess needs to generate it when running native. Config.guess is the only way to communicate the information needed for a native compiler when no other information is communicated on the command line, and it only reports a triplet. Why not fix this? For example, it could also give back configure options (--with-float=hard) that should be implicitly assumed to have been provided. That would be useful for GCC perhaps, but not for other projects that use config.guess (which is part of the generic GNU infrastructure). If those extra args could be made invisible to other users; then that might be a way forward. It really does seem like a hack to use triplets in this way; I think Paul's point that anything that depends on the toolchain triplet to determine ABI is inherently busted is pretty persuasive. Which means the whole GNU way of doing this has always been busted, since that's essentially how the world has always worked... :-) R.
Re: Triplet for ARM Linux HardFP ABI
It really does seem like a hack to use triplets in this way; I think Paul's point that anything that depends on the toolchain triplet to determine ABI is inherently busted is pretty persuasive. Which means the whole GNU way of doing this has always been busted, since that's essentially how the world has always worked... :-) Um, I though that GNU (autoconf) way of doing things was to test for features, rather than relying on hardcoded per-system mappings. Paul
Re: Triplet for ARM Linux HardFP ABI
Richard Earnshaw wrote: Why not fix this? For example, it could also give back configure options (--with-float=hard) that should be implicitly assumed to have been provided. That would be useful for GCC perhaps, but not for other projects that use config.guess (which is part of the generic GNU infrastructure). If those extra args could be made invisible to other users; then that might be a way forward. Presumably config.guess would be passed a new argument that causes it to produce this extra output. It really does seem like a hack to use triplets in this way; I think Paul's point that anything that depends on the toolchain triplet to determine ABI is inherently busted is pretty persuasive. Which means the whole GNU way of doing this has always been busted, since that's essentially how the world has always worked... :-) Well, indeed. There's always the question of when one ought to go clean up the mess and when one ought to just go with the flow. We've seen these kinds of problems on every embedded architecture; MIPS, for example, has suffered rather badly from this problem. Deriving ABI behavior from triplets is a problem that's caused brokenness for multilib'd toolchains in various packages. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
