[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: armelfp: new architecture name for an armel variant

On Thu, Jul 08, 2010, Wookey wrote:
> The first thing I've found is that whilst we can build for
> --mfloat-abi=hard there is no macro set by GCC to detect this state.

 For the record:

> manufacturer/vendor doesn't really supply useful information these
> days and is usually none or omitted.

 Yes, it's kind of optional free form text

> OS has been overloaded to include the ABI since the OABI ('gnu') EABI
> ('gnueabi') split. This isn't very pretty, but despite thinking about
> it for a while I haven't had any better ideas. I don't think that
> re-purposing the vendor/manufacturer field would really work, and
> adding a 5th field would also be a lot of pain (there are a lot of
> regexps in a lot of software to fix up). But if anyone does think it's
> a good idea then I don't mind taking a look at the practicalities.  

 Please, let's not use the last field; there is not only the default
 target of the toolchain, there is also the toolchain itself.  An
 arm-linux-gnueabi toolchain can target both soft and hard float calling
 conventions, so a single triplet.  It would be perfectly fine to use
 this triplet for toolchains/products built using either the soft or the
 hard float calling conventions.  The only issue is ... Debian's
 constraints.  Debian wants different triplets for dpkg and other
 reasons (e.g.  Multiarch).  Debian is a vendor and can use the vendor
 field.  Upstream software should ignore the vendor field, unless they
 know it.  It would be odd for us to invent an ABI which upstream
 doesn't know about (upstream knows about arm-linux-gnueabi) and force
 them to use it.

 The vendor is really the place for extensions IMO; I tried capturing
 this earlier piece of the discussion on the wiki page.

Loïc Minier

Reply to: