Re: [gentoo-mips] Re: On MIPS using the same CHOST for all multilib ABIs

[Markos Chandras <hwoarang@gentoo.org>]

On 12/29/2013 09:52 PM, Anthony G. Basile wrote:
> On 12/29/2013 04:48 PM, Markos Chandras wrote:
>> On 12/29/2013 09:48 PM, Michał Górny wrote:
>>> Dnia 2013-12-29, o godz. 16:40:08
>>> Joshua Kinard <kumba@gentoo.org> napisał(a):
>>>
>>>> On 12/28/2013 5:58 PM, Michał Górny wrote:
>>>>> I've noticed today that mips uses the same CHOST value for all three
>>>>> ABIs it supports:
>>>>>
>>>>> arch/mips/mips64/multilib/make.defaults:CHOST_o32="${CHOST}"
>>>>> arch/mips/mips64/multilib/make.defaults:CHOST_n32=${CHOST}
>>>>> arch/mips/mips64/multilib/make.defaults:CHOST_n64=${CHOST}
>>>>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_o32="${CHOST}"
>>>>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n32="${CHOST}"
>>>>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n64="${CHOST}"
>>>>>
>>>>> [...]
>>>>
>>>> Matt can probably vouch for this better, but the only two ABIs
>>>> affected by
>>>> this are n32 and n64.  mips[el]-unknown-linux-gnu implies a 32-bit
>>>> big/little endian CHOST, which means the o32 ABI.
>>>> mips64[el]-unknown-linux-gnu means either n32 or n64.  So no change
>>>> should
>>>> be needed for o32-based installs.
>>>
>>> Just to be clear:
>>>
>>> profiles/arch/mips/mipsel/mips64el/multilib/make.defaults:
>>>
>>> CHOST="mips64el-unknown-linux-gnu"
>>>
>>> [...]
>>>
>>> CFLAGS_o32="-mabi=32"
>>> CHOST_o32="${CHOST}"
>>>
>>> CFLAGS_n32="-mabi=n32"
>>> CHOST_n32="${CHOST}"
>>>
>>> CFLAGS_n64="-mabi=64"
>>> CHOST_n64="${CHOST}"
>>>
>>> So in this case, o32 actually uses mips64el-unknown-linux-gnu, unless
>>> I'm missing something.
>>>
>>
>> Yes all 3 ABIs use the same tuple.
>>
> 
> I think people are missing Mike's point from earlier, which is that
> tuples label toolchains and a toolchain can support multiple abis.  So
> for example, what would one do on a system which simultaneously has o32,
> n32 and n64?  -gnuabi32n32n64 looks pretty crazy.
> 
There is only one default ABI, so the toolchain should be named after
that. But that does not mean the toolchain can't build for different ABIs

-- 
Regards,
Markos Chandras