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

[Mark Hatle <mark.hatle@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

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

> 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.)

>>
>> 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@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.)

--Mark

> Missing or unbuildable dependency chain was: ['binutils-cross-canadian-mips64']
> NOTE: Runtime target 'packagegroup-cross-canadian-qemumips64n32' is
> unbuildable, removing...
> Missing or unbuildable dependency chain was:
> ['packagegroup-cross-canadian-qemumips64n32',
> 'binutils-cross-canadian-mips64']
> ERROR: Required build target 'core-image-base' has no buildable providers.
> Missing or unbuildable dependency chain was: ['core-image-base',
> 'packagegroup-cross-canadian-qemumips64n32',
> 'binutils-cross-canadian-mips64']
> 
> 
> 
>