> 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
