[Buildroot] [PATCH v2] Disable o32 ABI for MIPS64 architectures

[Buildroot] [PATCH v2] Disable o32 ABI for MIPS64 architectures

[Vicente Olivert Riera]

Building o32 ELF files for MIPS64 is an exotic configuration that nobody
should be using. If o32 is required, then is better if it's built for
MIPS 32-bit cores so only 32-bit instructions will be used leading to a
more efficient o32 usage.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
---
 arch/Config.in.mips |   12 +++++++-----
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/arch/Config.in.mips b/arch/Config.in.mips
index d9c0c02..f558705 100644
--- a/arch/Config.in.mips
+++ b/arch/Config.in.mips
@@ -38,15 +38,12 @@ endchoice
 
 choice
 	prompt "Target ABI"
-	depends on BR2_mips || BR2_mipsel || BR2_mips64 || BR2_mips64el
-	default BR2_MIPS_OABI32 if !BR2_ARCH_IS_64
-	default BR2_MIPS_NABI32 if BR2_ARCH_IS_64
+	depends on BR2_mips64 || BR2_mips64el
+	default BR2_MIPS_NABI32
 
 	help
 	  Application Binary Interface to use
 
-config BR2_MIPS_OABI32
-	bool "o32"
 config BR2_MIPS_NABI32
 	bool "n32"
 	depends on BR2_ARCH_IS_64
@@ -86,6 +83,11 @@ config BR2_GCC_TARGET_ARCH
 	default "mips64"	if BR2_mips_64
 	default "mips64r2"	if BR2_mips_64r2
 
+config BR2_MIPS_OABI32
+	bool
+	default y		if BR2_mips || BR2_mipsel
+	default n		if BR2_mips64 || BR2_mips64el
+
 config BR2_GCC_TARGET_ABI
 	default "32"		if BR2_MIPS_OABI32
 	default "n32"		if BR2_MIPS_NABI32
-- 
1.7.1

[Buildroot] [PATCH v2] Disable o32 ABI for MIPS64 architectures

[Arnout Vandecappelle]

On 25/03/14 18:52, Vicente Olivert Riera wrote:
> Building o32 ELF files for MIPS64 is an exotic configuration that nobody
> should be using. If o32 is required, then is better if it's built for
> MIPS 32-bit cores so only 32-bit instructions will be used leading to a
> more efficient o32 usage.
> 
> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> ---
>  arch/Config.in.mips |   12 +++++++-----
>  1 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/Config.in.mips b/arch/Config.in.mips
> index d9c0c02..f558705 100644
> --- a/arch/Config.in.mips
> +++ b/arch/Config.in.mips
> @@ -38,15 +38,12 @@ endchoice
>  
>  choice
>  	prompt "Target ABI"
> -	depends on BR2_mips || BR2_mipsel || BR2_mips64 || BR2_mips64el
> -	default BR2_MIPS_OABI32 if !BR2_ARCH_IS_64
> -	default BR2_MIPS_NABI32 if BR2_ARCH_IS_64
> +	depends on BR2_mips64 || BR2_mips64el
> +	default BR2_MIPS_NABI32
>  
>  	help
>  	  Application Binary Interface to use
>  
> -config BR2_MIPS_OABI32
> -	bool "o32"
>  config BR2_MIPS_NABI32
>  	bool "n32"
>  	depends on BR2_ARCH_IS_64
> @@ -86,6 +83,11 @@ config BR2_GCC_TARGET_ARCH
>  	default "mips64"	if BR2_mips_64
>  	default "mips64r2"	if BR2_mips_64r2
>  
> +config BR2_MIPS_OABI32
> +	bool
> +	default y		if BR2_mips || BR2_mipsel
> +	default n		if BR2_mips64 || BR2_mips64el

 The default n isn't needed - that is the default already in all other cases.

> +
>  config BR2_GCC_TARGET_ABI
>  	default "32"		if BR2_MIPS_OABI32
>  	default "n32"		if BR2_MIPS_NABI32
> 

 Normally we should have a Config.in.legacy entry to catch old .configs
that have o32 for a mips64 target. However, that is not possible now.
Therefore, it should be captured in the release notes. To make sure that
Peter doesn't forget, can you add this to the top of CHANGES?


2014.05, Not yet released:

Support for MIPS o32 ABI on MIPS-64 targets has been removed. Building
o32 ELF files for MIPS64 is an exotic configuration that nobody should be
using. If o32 is required, then is better if it's built for MIPS 32-bit
cores so only 32-bit instructions will be used leading to a more
efficient o32 usage.




 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH v2] Disable o32 ABI for MIPS64 architectures

[Joshua Kinard]

On 03/25/2014 16:02, Arnout Vandecappelle wrote:
> On 25/03/14 18:52, Vicente Olivert Riera wrote:
>> Building o32 ELF files for MIPS64 is an exotic configuration that nobody
>> should be using. If o32 is required, then is better if it's built for
>> MIPS 32-bit cores so only 32-bit instructions will be used leading to a
>> more efficient o32 usage.
>>
>> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
>> ---
>>  arch/Config.in.mips |   12 +++++++-----
>>  1 files changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/Config.in.mips b/arch/Config.in.mips
>> index d9c0c02..f558705 100644
>> --- a/arch/Config.in.mips
>> +++ b/arch/Config.in.mips
>> @@ -38,15 +38,12 @@ endchoice
>>  
>>  choice
>>  	prompt "Target ABI"
>> -	depends on BR2_mips || BR2_mipsel || BR2_mips64 || BR2_mips64el
>> -	default BR2_MIPS_OABI32 if !BR2_ARCH_IS_64
>> -	default BR2_MIPS_NABI32 if BR2_ARCH_IS_64
>> +	depends on BR2_mips64 || BR2_mips64el
>> +	default BR2_MIPS_NABI32
>>  
>>  	help
>>  	  Application Binary Interface to use
>>  
>> -config BR2_MIPS_OABI32
>> -	bool "o32"
>>  config BR2_MIPS_NABI32
>>  	bool "n32"
>>  	depends on BR2_ARCH_IS_64
>> @@ -86,6 +83,11 @@ config BR2_GCC_TARGET_ARCH
>>  	default "mips64"	if BR2_mips_64
>>  	default "mips64r2"	if BR2_mips_64r2
>>  
>> +config BR2_MIPS_OABI32
>> +	bool
>> +	default y		if BR2_mips || BR2_mipsel
>> +	default n		if BR2_mips64 || BR2_mips64el
> 
>  The default n isn't needed - that is the default already in all other cases.
> 
>> +
>>  config BR2_GCC_TARGET_ABI
>>  	default "32"		if BR2_MIPS_OABI32
>>  	default "n32"		if BR2_MIPS_NABI32
>>
> 
>  Normally we should have a Config.in.legacy entry to catch old .configs
> that have o32 for a mips64 target. However, that is not possible now.
> Therefore, it should be captured in the release notes. To make sure that
> Peter doesn't forget, can you add this to the top of CHANGES?
> 
> 
> 2014.05, Not yet released:
> 
> Support for MIPS o32 ABI on MIPS-64 targets has been removed. Building
> o32 ELF files for MIPS64 is an exotic configuration that nobody should be
> using. If o32 is required, then is better if it's built for MIPS 32-bit
> cores so only 32-bit instructions will be used leading to a more
> efficient o32 usage.

Just to point out, I wouldn't call this "exotic" -- o32 on mips64 kernels
(MIPS-IV ISA) is what I run on my SGI O2 under Gentoo.  That said, I do have
a somewhat-working n32 chroot on the same box.  Additionally, isn't o32 the
ABI that Debian still builds for most of their mips/mipsel targets?

I guess for newer MIPS hardware, this is definitely sensible, but given the
wide availability of old SGI hardware on eBay, it's far from exotic.  I also
believe Debian still supports DEC systems, which are even older.

I still plan on looking at fixing the MIPS-II to MIPS-IV issue I raised a
few weeks ago, but I've been tied up in other projects.  So if there is some
legacy way to retain this capability, maybe by defining an SGI-specific
target at some point, that'd be great.  It'll at least give me a starting
port to isolate the legacy stuff so that it only applies to this old
hardware and doesn't impede anyone working with newer hardware.

Food for thought :)

-- 
Joshua Kinard
Gentoo/MIPS
kumba at gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

[Buildroot] [PATCH v2] Disable o32 ABI for MIPS64 architectures

[Markos Chandras]

On 03/26/2014 12:14 AM, Joshua Kinard wrote:
> On 03/25/2014 16:02, Arnout Vandecappelle wrote:
>> On 25/03/14 18:52, Vicente Olivert Riera wrote:
>>> Building o32 ELF files for MIPS64 is an exotic configuration that nobody
>>> should be using. If o32 is required, then is better if it's built for
>>> MIPS 32-bit cores so only 32-bit instructions will be used leading to a
>>> more efficient o32 usage.
>>>
>>> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
>>> ---
>>>   arch/Config.in.mips |   12 +++++++-----
>>>   1 files changed, 7 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch/Config.in.mips b/arch/Config.in.mips
>>> index d9c0c02..f558705 100644
>>> --- a/arch/Config.in.mips
>>> +++ b/arch/Config.in.mips
>>> @@ -38,15 +38,12 @@ endchoice
>>>
>>>   choice
>>>   	prompt "Target ABI"
>>> -	depends on BR2_mips || BR2_mipsel || BR2_mips64 || BR2_mips64el
>>> -	default BR2_MIPS_OABI32 if !BR2_ARCH_IS_64
>>> -	default BR2_MIPS_NABI32 if BR2_ARCH_IS_64
>>> +	depends on BR2_mips64 || BR2_mips64el
>>> +	default BR2_MIPS_NABI32
>>>
>>>   	help
>>>   	  Application Binary Interface to use
>>>
>>> -config BR2_MIPS_OABI32
>>> -	bool "o32"
>>>   config BR2_MIPS_NABI32
>>>   	bool "n32"
>>>   	depends on BR2_ARCH_IS_64
>>> @@ -86,6 +83,11 @@ config BR2_GCC_TARGET_ARCH
>>>   	default "mips64"	if BR2_mips_64
>>>   	default "mips64r2"	if BR2_mips_64r2
>>>
>>> +config BR2_MIPS_OABI32
>>> +	bool
>>> +	default y		if BR2_mips || BR2_mipsel
>>> +	default n		if BR2_mips64 || BR2_mips64el
>>
>>   The default n isn't needed - that is the default already in all other cases.
>>
>>> +
>>>   config BR2_GCC_TARGET_ABI
>>>   	default "32"		if BR2_MIPS_OABI32
>>>   	default "n32"		if BR2_MIPS_NABI32
>>>
>>
>>   Normally we should have a Config.in.legacy entry to catch old .configs
>> that have o32 for a mips64 target. However, that is not possible now.
>> Therefore, it should be captured in the release notes. To make sure that
>> Peter doesn't forget, can you add this to the top of CHANGES?
>>
>>
>> 2014.05, Not yet released:
>>
>> Support for MIPS o32 ABI on MIPS-64 targets has been removed. Building
>> o32 ELF files for MIPS64 is an exotic configuration that nobody should be
>> using. If o32 is required, then is better if it's built for MIPS 32-bit
>> cores so only 32-bit instructions will be used leading to a more
>> efficient o32 usage.
>
> Just to point out, I wouldn't call this "exotic" -- o32 on mips64 kernels
> (MIPS-IV ISA) is what I run on my SGI O2 under Gentoo.  That said, I do have
> a somewhat-working n32 chroot on the same box.  Additionally, isn't o32 the
> ABI that Debian still builds for most of their mips/mipsel targets?

We are talking about using 64-bit instructions in *userland* while 
maintaining the o32 ABI semantics. Well, this is definitely an exotic 
configuration. We are not talking about 64-bit kernels + o32 userland.
An o32 userland usually comes from mips32 and you usually have only 
32-bit instructions there.

-- 
markos

[Buildroot] [PATCH v2] Disable o32 ABI for MIPS64 architectures

[Vicente Olivert Riera]

On 03/26/2014 02:19 PM, Markos Chandras wrote:
> On 03/26/2014 12:14 AM, Joshua Kinard wrote:
>> On 03/25/2014 16:02, Arnout Vandecappelle wrote:
>>> On 25/03/14 18:52, Vicente Olivert Riera wrote:
>>>> Building o32 ELF files for MIPS64 is an exotic configuration that
>>>> nobody
>>>> should be using. If o32 is required, then is better if it's built for
>>>> MIPS 32-bit cores so only 32-bit instructions will be used leading to a
>>>> more efficient o32 usage.
>>>>
>>>> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
>>>> ---
>>>>   arch/Config.in.mips |   12 +++++++-----
>>>>   1 files changed, 7 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/arch/Config.in.mips b/arch/Config.in.mips
>>>> index d9c0c02..f558705 100644
>>>> --- a/arch/Config.in.mips
>>>> +++ b/arch/Config.in.mips
>>>> @@ -38,15 +38,12 @@ endchoice
>>>>
>>>>   choice
>>>>       prompt "Target ABI"
>>>> -    depends on BR2_mips || BR2_mipsel || BR2_mips64 || BR2_mips64el
>>>> -    default BR2_MIPS_OABI32 if !BR2_ARCH_IS_64
>>>> -    default BR2_MIPS_NABI32 if BR2_ARCH_IS_64
>>>> +    depends on BR2_mips64 || BR2_mips64el
>>>> +    default BR2_MIPS_NABI32
>>>>
>>>>       help
>>>>         Application Binary Interface to use
>>>>
>>>> -config BR2_MIPS_OABI32
>>>> -    bool "o32"
>>>>   config BR2_MIPS_NABI32
>>>>       bool "n32"
>>>>       depends on BR2_ARCH_IS_64
>>>> @@ -86,6 +83,11 @@ config BR2_GCC_TARGET_ARCH
>>>>       default "mips64"    if BR2_mips_64
>>>>       default "mips64r2"    if BR2_mips_64r2
>>>>
>>>> +config BR2_MIPS_OABI32
>>>> +    bool
>>>> +    default y        if BR2_mips || BR2_mipsel
>>>> +    default n        if BR2_mips64 || BR2_mips64el
>>>
>>>   The default n isn't needed - that is the default already in all
>>> other cases.
>>>
>>>> +
>>>>   config BR2_GCC_TARGET_ABI
>>>>       default "32"        if BR2_MIPS_OABI32
>>>>       default "n32"        if BR2_MIPS_NABI32
>>>>
>>>
>>>   Normally we should have a Config.in.legacy entry to catch old .configs
>>> that have o32 for a mips64 target. However, that is not possible now.
>>> Therefore, it should be captured in the release notes. To make sure that
>>> Peter doesn't forget, can you add this to the top of CHANGES?
>>>
>>>
>>> 2014.05, Not yet released:
>>>
>>> Support for MIPS o32 ABI on MIPS-64 targets has been removed. Building
>>> o32 ELF files for MIPS64 is an exotic configuration that nobody
>>> should be
>>> using. If o32 is required, then is better if it's built for MIPS 32-bit
>>> cores so only 32-bit instructions will be used leading to a more
>>> efficient o32 usage.
>>
>> Just to point out, I wouldn't call this "exotic" -- o32 on mips64 kernels
>> (MIPS-IV ISA) is what I run on my SGI O2 under Gentoo.  That said, I
>> do have
>> a somewhat-working n32 chroot on the same box.  Additionally, isn't
>> o32 the
>> ABI that Debian still builds for most of their mips/mipsel targets?
>
> We are talking about using 64-bit instructions in *userland* while
> maintaining the o32 ABI semantics. Well, this is definitely an exotic
> configuration. We are not talking about 64-bit kernels + o32 userland.
> An o32 userland usually comes from mips32 and you usually have only
> 32-bit instructions there.
>

V3 sent: http://patchwork.ozlabs.org/patch/333959/

-- 
Vincent

[Buildroot] [PATCH v2] Disable o32 ABI for MIPS64 architectures

[Arnout Vandecappelle]

 Hi Joshua,

On 26/03/14 15:19, Markos Chandras wrote:
> On 03/26/2014 12:14 AM, Joshua Kinard wrote:
>> On 03/25/2014 16:02, Arnout Vandecappelle wrote:
[snip]
>>> Support for MIPS o32 ABI on MIPS-64 targets has been removed. Building
>>> o32 ELF files for MIPS64 is an exotic configuration that nobody should be
>>> using. If o32 is required, then is better if it's built for MIPS 32-bit
>>> cores so only 32-bit instructions will be used leading to a more
>>> efficient o32 usage.
>>
>> Just to point out, I wouldn't call this "exotic" -- o32 on mips64 kernels
>> (MIPS-IV ISA) is what I run on my SGI O2 under Gentoo.  That said, I do
>> have
>> a somewhat-working n32 chroot on the same box.  Additionally, isn't o32

 So the mips64 n32 userspace created by buildroot doesn't work
completely, just somewhat?

>> the
>> ABI that Debian still builds for most of their mips/mipsel targets?

 What Debian does is really not relevant here...

> 
> We are talking about using 64-bit instructions in *userland* while
> maintaining the o32 ABI semantics. Well, this is definitely an exotic
> configuration. We are not talking about 64-bit kernels + o32 userland.
> An o32 userland usually comes from mips32 and you usually have only
> 32-bit instructions there.

 Joshua, if you agree with this reasoning, could you ack Vicente's patch?

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH v2] Disable o32 ABI for MIPS64 architectures

[Joshua Kinard]

On 03/26/2014 10:19, Markos Chandras wrote:
> On 03/26/2014 12:14 AM, Joshua Kinard wrote:
>> On 03/25/2014 16:02, Arnout Vandecappelle wrote:
>>> On 25/03/14 18:52, Vicente Olivert Riera wrote:
[snip]
>>> Support for MIPS o32 ABI on MIPS-64 targets has been removed. Building
>>> o32 ELF files for MIPS64 is an exotic configuration that nobody should be
>>> using. If o32 is required, then is better if it's built for MIPS 32-bit
>>> cores so only 32-bit instructions will be used leading to a more
>>> efficient o32 usage.
>>
>> Just to point out, I wouldn't call this "exotic" -- o32 on mips64 kernels
>> (MIPS-IV ISA) is what I run on my SGI O2 under Gentoo.  That said, I do have
>> a somewhat-working n32 chroot on the same box.  Additionally, isn't o32 the
>> ABI that Debian still builds for most of their mips/mipsel targets?
> 
> We are talking about using 64-bit instructions in *userland* while
> maintaining the o32 ABI semantics. Well, this is definitely an exotic
> configuration. We are not talking about 64-bit kernels + o32 userland.
> An o32 userland usually comes from mips32 and you usually have only 32-bit
> instructions there.

I think the mixup I am having is the "MIPS64" that Vincent is referring to
is the ISA, e.g., mips64r[12], not "MIPS64" as in "64bit MIPS", right?

-- 
Joshua Kinard
Gentoo/MIPS
kumba at gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

[Buildroot] [PATCH v2] Disable o32 ABI for MIPS64 architectures

[Joshua Kinard]

On 03/26/2014 13:17, Arnout Vandecappelle wrote:
> 
>  Hi Joshua,
> 
> On 26/03/14 15:19, Markos Chandras wrote:
>> On 03/26/2014 12:14 AM, Joshua Kinard wrote:
>>> On 03/25/2014 16:02, Arnout Vandecappelle wrote:
> [snip]
>>>> Support for MIPS o32 ABI on MIPS-64 targets has been removed. Building
>>>> o32 ELF files for MIPS64 is an exotic configuration that nobody should be
>>>> using. If o32 is required, then is better if it's built for MIPS 32-bit
>>>> cores so only 32-bit instructions will be used leading to a more
>>>> efficient o32 usage.
>>>
>>> Just to point out, I wouldn't call this "exotic" -- o32 on mips64 kernels
>>> (MIPS-IV ISA) is what I run on my SGI O2 under Gentoo.  That said, I do
>>> have
>>> a somewhat-working n32 chroot on the same box.  Additionally, isn't o32
> 
>  So the mips64 n32 userspace created by buildroot doesn't work
> completely, just somewhat?

No, "somewhat" means I haven't powered that machine up in a while and
updated it.  It boots into an o32 install I've had since 2005 (and am loathe
to replace just yet, at least as long as the disks stay alive), and I chroot
into a separate n32 root.  It's got an old 350MHz RM7000 CPU (PMC-Sierra),
so updating can take a long time for just the o32 root (gcc is ~17hrs these
days.  Used to be ~2.5hrs in the gcc-3.4.x days).  Once that's updated, I
then update the n32 root.  Almost had that done until a recent snow storm
knocked my power out, and I never resumed the update.


>> We are talking about using 64-bit instructions in *userland* while
>> maintaining the o32 ABI semantics. Well, this is definitely an exotic
>> configuration. We are not talking about 64-bit kernels + o32 userland.
>> An o32 userland usually comes from mips32 and you usually have only
>> 32-bit instructions there.
> 
>  Joshua, if you agree with this reasoning, could you ack Vicente's patch?

Let me get clarification on what "MIPS64" Vincent was referring to first.
It's easy to mix that up.  I was assuming he meant o32 userland + mips64
kernel, which I know still works, even though it is very inefficient (using
just half of your available CPU registers).  If he's referring to the ISA of
MIPS64 (or as I read it, mips64r1/mips64r2), then yeah, it's not a problem
at all.  Though I am not an authority on MIPS' capabilities outside of the
SGI hardware lineup, as that's all that I have available to play with.


-- 
Joshua Kinard
Gentoo/MIPS
kumba at gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

[Buildroot] [PATCH v2] Disable o32 ABI for MIPS64 architectures

[Markos Chandras]

On 03/26/2014 11:45 PM, Joshua Kinard wrote:
> On 03/26/2014 13:17, Arnout Vandecappelle wrote:
>>
>>   Hi Joshua,
>>
>> On 26/03/14 15:19, Markos Chandras wrote:
>>> On 03/26/2014 12:14 AM, Joshua Kinard wrote:
>>>> On 03/25/2014 16:02, Arnout Vandecappelle wrote:
>> [snip]
>>>>> Support for MIPS o32 ABI on MIPS-64 targets has been removed. Building
>>>>> o32 ELF files for MIPS64 is an exotic configuration that nobody should be
>>>>> using. If o32 is required, then is better if it's built for MIPS 32-bit
>>>>> cores so only 32-bit instructions will be used leading to a more
>>>>> efficient o32 usage.
>>>>
>>>> Just to point out, I wouldn't call this "exotic" -- o32 on mips64 kernels
>>>> (MIPS-IV ISA) is what I run on my SGI O2 under Gentoo.  That said, I do
>>>> have
>>>> a somewhat-working n32 chroot on the same box.  Additionally, isn't o32
>>
>>   So the mips64 n32 userspace created by buildroot doesn't work
>> completely, just somewhat?
>
> No, "somewhat" means I haven't powered that machine up in a while and
> updated it.  It boots into an o32 install I've had since 2005 (and am loathe
> to replace just yet, at least as long as the disks stay alive), and I chroot
> into a separate n32 root.  It's got an old 350MHz RM7000 CPU (PMC-Sierra),
> so updating can take a long time for just the o32 root (gcc is ~17hrs these
> days.  Used to be ~2.5hrs in the gcc-3.4.x days).  Once that's updated, I
> then update the n32 root.  Almost had that done until a recent snow storm
> knocked my power out, and I never resumed the update.
>
>
>>> We are talking about using 64-bit instructions in *userland* while
>>> maintaining the o32 ABI semantics. Well, this is definitely an exotic
>>> configuration. We are not talking about 64-bit kernels + o32 userland.
>>> An o32 userland usually comes from mips32 and you usually have only
>>> 32-bit instructions there.
>>
>>   Joshua, if you agree with this reasoning, could you ack Vicente's patch?
>
> Let me get clarification on what "MIPS64" Vincent was referring to first.
> It's easy to mix that up.  I was assuming he meant o32 userland + mips64
> kernel, which I know still works, even though it is very inefficient (using
> just half of your available CPU registers).  If he's referring to the ISA of
> MIPS64 (or as I read it, mips64r1/mips64r2), then yeah, it's not a problem
> at all.  Though I am not an authority on MIPS' capabilities outside of the
> SGI hardware lineup, as that's all that I have available to play with.
>
>

Yes, maybe the commit message was confusing. We definitely did not mean 
mips64 kernel + o32 userland. We meant 64-bit userland + o32 ABI.

So I guess we are all good here :)

-- 
markos