[OE-core] [PATCH 1/3] arch-mips.inc: don't override TRANSLATED_TARGET_ARCH

[Dmitry Eremin-Solenikov]

Hello,

2015-06-19 17:01 GMT+03:00 Mark Hatle <mark.hatle at windriver.com>:
> On 6/19/15 4:23 AM, Dmitry Eremin-Solenikov wrote:
>>> On 6/18/15 8:13 AM, Dmitry Eremin-Solenikov wrote:
>>>> Currently MIPS64 N32 is broken. There is internal disagreement
>>>> between TARGET_ARCH (which doesn't contain ABIEXTENSION) and
>>>> TRANSLATED_TARGET_ARCH (which contains ABIEXTENSION). ABI is already
>>>> encoded into the TARGET_OS. ARM tunes in the same situation override
>>>> neither the TARGET_ARCH nor the TRANSLATED_TARGET_ARCH. So let's drop
>>>> this override.
>>>
>>> This series won't work properly, unless I'm reading something incorrectly.
>>>
>>> You won't be able to build/install a tri-lib system after this change, as
>>> something needs to be there to differential between MIPS32 (o32), MIPS64 (n32)
>>> and MIPS64 (n64).
>>>
>>> Currently this is done via the ABIEXTENSION value.
>>
>> Why do you need this differentiation in the TARGET_ARCH? We have TARGET_SYS
>> (triplets) for that, don't we? And the compilers for the N64/N32 (the
>> only thing IIRC
>> that is really dependent on the TARGET_ARCH) should be interchangeable, AFAIU.
>
> The triplet for o32 is:
>
> mips-os-linux
>
> The triplet to n64 is:
>
> mips64-os-linux
>
> The triplet to n32 is:
>
> mips64-os-linux

No. It is mips64-oe-linux-gnun32! Even with my patches.


> thus w/o the ABI extension there is no mechanism to distinguish between n64 and n32.

See, the arch is the same (MIPS64), it should not encode the ABI. The
multiplet differs
(mips64-oe-linux vs. mips64-oe-linux-gnun32) and this also looks correct.

>
>> Can you point me, please, how to create a tri-ABI SDK and/or image?
>
> Configure with a MIPS64 capable machine (yes qemumips64 is adequate).  Then add
> the following to your local.conf:
>
> require conf/multilib.conf
> DEFAULTTUNE = "mips32r2"
>
> MULTILIBS = "multilib:lib32 multilib:lib64"
> DEFAULTTUNE_virtclass-multilib-lib32 = "mips64-n32"
> DEFAULTTUNE_virtclass-multilib-lib64 = "mips64"
>
>
> This will set the default ABI to 'o32', with optional n32 and n64 support.  (You
> can switch around the defaulttune values to change which is default and which is
> optional.  A common config is n32 default, o32 / n64 optional.)

I'll try with this with my patches.

>
>>>
>>> What is currently broken w/ MIPS64 N32?  We put in a number of fixes for this
>>> problem and SDK generation in the YP 1.8 time frame.  Perhaps something has
>>> changed since then or maybe the fixes were not as complete as we thought?
>>
>> Quite simple configuration (MIPS64 N32 image) fails to build.
>>
>>
>> lumag at nexs:~/OE$ MACHINE=qemumips64n32 bitbake core-image-base
>> NOTE: Started PRServer with DBfile:
>> /home/lumag/OE/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 46391, PID:
>> 15895
>> Loading cache: 100%
>> |########################################################################################################################|
>> ETA:  00:00:00
>> Loaded 1302 entries from dependency cache.
>> NOTE: Resolving any missing task queue dependencies
>> ERROR: Nothing RPROVIDES 'binutils-cross-canadian-mips64' (but
>> /home/lumag/OE/sources/openembedded-core/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb
>> RDEPENDS on or otherwise requires it)
>> NOTE: Runtime target 'binutils-cross-canadian-mips64' is unbuildable,
>> removing...
>
> Looks to me that when binutils was upgraded, the rename of the arch component
> broke in some way.  The arch renaming used by the cross-canadian toolchain
> components SHOULD have changed things to me "mips64-n32" in the n32 case.  This
> is the purpose of the ABIEXTENSION being added to the 'TRANSLATED_TARGET_ARCH'
> in arch-mips.conf.  See commit: 0bcc01121e928d0be7a0550e500425852c63cf98 for
> additional details.
>
> (The commit msg includes the configuration listed above as well.)



-- 
With best wishes
Dmitry