gdb vs. gdbserver with -mips3 / 32bitmode userspace

gdb vs. gdbserver with -mips3 / 32bitmode userspace

[Johannes Stezenbach]

Hi,

I'm trying to debug a userspace application with gdb-6.3 / gdbserver.
Objdump -p reports:
  private flags = 20001107: [abi=O32] [mips3] [32bitmode]

With gdb-6.0 from an older toolchain this works, but gdb-6.3
reports the infamous "Reply contains invalid hex digit 59".
The reason for this is that gdb and gdbserver disagree
about the register size. Gdbserver seems to be hardcoded
to 32bit register size (regformats/reg-mips.dat), while gdb-6.3 assumes
that mips3 binaries use 64bit registers. (Actually E_MIPS_ARCH_3
gets transformed into bfd_mach_mips4000 in bfd/elfxx-mips.c, which
has 64bit registers according to bfd/cpu-mips.c).

(I briefly checked gdb-6.4, it seems to do the same.)

The workaround given in this posting seems to work for
userspace, too:
http://www.linux-mips.org/archives/linux-mips/2005-11/msg00154.html
I.e. "set architecture mips:isa32" overrides the register size
which gdb uses to talk to gdbserver.

However, I wonder why gdb doesn't evaluate the 32bitmode flag
from the ELF e_flags header. To be honest, I also wonder what
the exact semantics of this flag are. The NUBI document says:

  "32BIT_MODE: (e_flags&EF_MIPS_32BITMODE) - 1 when code assumes 32-bit
  registers only. Always set for NUBI32, but NUBI-compliant software
  should not rely on it."

I think (maybe in error ;-), that all binaries compiled for
a 32bit ABI, but a 64bit ISA, have this flag set, as the kernel
will refuse to execute 64bt code (i.e. not o32 or n32 ABI). Therefore,
shouldn't gdb also evaluate this flag when deciding about the ISA
register size?

How about this patch:


--- gdb-6.3/gdb/mips-tdep.c.orig	2004-10-15 09:25:03.000000000 +0200
+++ gdb-6.3/gdb/mips-tdep.c	2006-01-30 21:13:09.000000000 +0100
@@ -258,6 +258,15 @@ mips_abi (struct gdbarch *gdbarch)
 int
 mips_isa_regsize (struct gdbarch *gdbarch)
 {
+  struct gdbarch_tdep *tdep = gdbarch_tdep (current_gdbarch);
+  if (tdep != NULL)
+    {
+      int ef_mips_32bitmode;
+      ef_mips_32bitmode = (tdep->elf_flags & EF_MIPS_32BITMODE);
+      if (ef_mips_32bitmode)
+        return 4;
+    }
+
   return (gdbarch_bfd_arch_info (gdbarch)->bits_per_word
 	  / gdbarch_bfd_arch_info (gdbarch)->bits_per_byte);
 }


I also considered if adding 64bit support to gdbserver would be
the right thing, but I think not as o32 ABI executables don't have
64bit registers, right?

Please don't be too hard on me, my understanding of gdb etc. is pretty
limited. I'm especially confused by this ISA regsize vs. ABI regsize
thing ;-/. Thus my patch looks at the 32bitmode flag and not at
the o32 ABI to decide about this register size, however I'm not
sure if any of this makes actually sense. It seems to work for me,
though ;-)

But I'd be willing to do some work to get this fixed properly in
upstream gdb, if I get some guidance.


Thanks,
Johannes

Re: gdb vs. gdbserver with -mips3 / 32bitmode userspace

[Maciej W. Rozycki]

On Tue, 31 Jan 2006, Johannes Stezenbach wrote:

> I think (maybe in error ;-), that all binaries compiled for
> a 32bit ABI, but a 64bit ISA, have this flag set, as the kernel
> will refuse to execute 64bt code (i.e. not o32 or n32 ABI). Therefore,
> shouldn't gdb also evaluate this flag when deciding about the ISA
> register size?

 O32 implies 32-bit registers no matter what ISA is specified (while 
o32/MIPS-III is effectively o32/MIPS-II, o32/MIPS-IV makes a difference), 
therefore it's a bug.  You should try sending your proposal to 
<gdb-patches@sources.redhat.com> instead.  But I smell the problem is 
elsewhere -- mips_isa_regsize() shouldn't be called for the "cooked" 
registers and these are ones you should only see under Linux or, as a 
matter of fact, any hosted environment.  See mips_register_type() for a 
start.

  Maciej

Re: gdb vs. gdbserver with -mips3 / 32bitmode userspace

[Johannes Stezenbach]

On Tue, Jan 31, 2006, Maciej W. Rozycki wrote:
> On Tue, 31 Jan 2006, Johannes Stezenbach wrote:
> 
> > I think (maybe in error ;-), that all binaries compiled for
> > a 32bit ABI, but a 64bit ISA, have this flag set, as the kernel
> > will refuse to execute 64bt code (i.e. not o32 or n32 ABI). Therefore,
> > shouldn't gdb also evaluate this flag when deciding about the ISA
> > register size?
> 
>  O32 implies 32-bit registers no matter what ISA is specified (while 
> o32/MIPS-III is effectively o32/MIPS-II, o32/MIPS-IV makes a difference), 
> therefore it's a bug.  You should try sending your proposal to 
> <gdb-patches@sources.redhat.com> instead.  But I smell the problem is 
> elsewhere -- mips_isa_regsize() shouldn't be called for the "cooked" 
> registers and these are ones you should only see under Linux or, as a 
> matter of fact, any hosted environment.  See mips_register_type() for a 
> start.

Yes, that's why I said I'm confused about mips_isa_regsize() vs.
mips_abi_regsize().

mips_abi_regsize() correctly says the register size is 32bit for o32,
but mips_register_type() calls mips_isa_regsize(), not
mips_abi_regsize(). That's why I chose to "fix" mips_isa_regsize().

Or should mips_register_type() simply call mips_abi_regsize()?

Or is the correct fix to change gdbserver to transfer registers
in mips_isa_regsize() size, i.e. 64bit for 64bit ISA?
(But gdb would't use the upper 32bits of the registers anyway
with o32 ABI, and this would be more complicated to fix.)

I can't decide :-(


Johannes

Re: gdb vs. gdbserver with -mips3 / 32bitmode userspace

[Thiemo Seufer]

On Tue, Jan 31, 2006 at 07:14:14PM +0100, Johannes Stezenbach wrote:
[snip]
> Yes, that's why I said I'm confused about mips_isa_regsize() vs.
> mips_abi_regsize().
> 
> mips_abi_regsize() correctly says the register size is 32bit for o32,
> but mips_register_type() calls mips_isa_regsize(), not
> mips_abi_regsize(). That's why I chose to "fix" mips_isa_regsize().
> 
> Or should mips_register_type() simply call mips_abi_regsize()?

Without having had a look at the code I think that's the right fix.

> Or is the correct fix to change gdbserver to transfer registers
> in mips_isa_regsize() size, i.e. 64bit for 64bit ISA?
> (But gdb would't use the upper 32bits of the registers anyway
> with o32 ABI, and this would be more complicated to fix.)


Thiemo

Re: gdb vs. gdbserver with -mips3 / 32bitmode userspace

[Johannes Stezenbach]

On Tue, Jan 31, 2006, Thiemo Seufer wrote:
> On Tue, Jan 31, 2006 at 07:14:14PM +0100, Johannes Stezenbach wrote:
> [snip]
> > Yes, that's why I said I'm confused about mips_isa_regsize() vs.
> > mips_abi_regsize().
> > 
> > mips_abi_regsize() correctly says the register size is 32bit for o32,
> > but mips_register_type() calls mips_isa_regsize(), not
> > mips_abi_regsize(). That's why I chose to "fix" mips_isa_regsize().
> > 
> > Or should mips_register_type() simply call mips_abi_regsize()?
> 
> Without having had a look at the code I think that's the right fix.

OK, I'll test if that works for me, and post results here
and to gdb-patches@sources.redhat.com.

Thanks,
Johannes

Re: gdb vs. gdbserver with -mips3 / 32bitmode userspace

[Daniel Jacobowitz]

On Tue, Jan 31, 2006 at 05:36:13PM +0000, Maciej W. Rozycki wrote:
> On Tue, 31 Jan 2006, Johannes Stezenbach wrote:
> 
> > I think (maybe in error ;-), that all binaries compiled for
> > a 32bit ABI, but a 64bit ISA, have this flag set, as the kernel
> > will refuse to execute 64bt code (i.e. not o32 or n32 ABI). Therefore,
> > shouldn't gdb also evaluate this flag when deciding about the ISA
> > register size?
> 
>  O32 implies 32-bit registers no matter what ISA is specified (while 
> o32/MIPS-III is effectively o32/MIPS-II, o32/MIPS-IV makes a difference), 
> therefore it's a bug.  You should try sending your proposal to 
> <gdb-patches@sources.redhat.com> instead.  But I smell the problem is 
> elsewhere -- mips_isa_regsize() shouldn't be called for the "cooked" 
> registers and these are ones you should only see under Linux or, as a 
> matter of fact, any hosted environment.  See mips_register_type() for a 
> start.

All of this code is flat-out wrong, as far as I'm concerned.  I have a
project underway which will fix it, as a nice side effect.

GDB is trying to do something confusing, but admirable, here.  When
you're running on a 64-bit system the full 64 bits are always there:
even if the binary only uses half of them (is this true in Linux?  I
don't remember if the relevant control bits get fudged, it's been a
while; it's definitely true on some other systems).  Thus it's possible
for a bogus instruction to corrupt the top half of a register, leading
to otherwise inexplicable problems.

So if the remote stub knows about 64-bit registers, it should report
them to GDB, and GDB should accept and display them, and still handle
32-bit frames.  If the remote stub doesn't, then there's no option but
to report the 32-bit registers.

Really, GDB ought to (and soon will I hope) autodetect which ones were
sent.

-- 
Daniel Jacobowitz
CodeSourcery

Re: gdb vs. gdbserver with -mips3 / 32bitmode userspace

[Maciej W. Rozycki]

On Wed, 1 Feb 2006, Daniel Jacobowitz wrote:

> All of this code is flat-out wrong, as far as I'm concerned.  I have a
> project underway which will fix it, as a nice side effect.

 Great!.

> GDB is trying to do something confusing, but admirable, here.  When
> you're running on a 64-bit system the full 64 bits are always there:
> even if the binary only uses half of them (is this true in Linux?  I
> don't remember if the relevant control bits get fudged, it's been a
> while; it's definitely true on some other systems).  Thus it's possible
> for a bogus instruction to corrupt the top half of a register, leading
> to otherwise inexplicable problems.

 Well, cp0.status.ux is always set with a 64-bit kernel.  It is not with a 
32-bit one.  A binary marked as o32/MIPS-III will work with either as long 
as 64-bit operations are not used.  For implementations that provide the 
cp0.status.xx bit, it is always set so that at least 32-bit MIPS-IV 
instructions work.

  Maciej

RE: gdb vs. gdbserver with -mips3 / 32bitmode userspace

[Michael Uhler]

Daniel,

The O/S maybe doing something different, but the architecture has 3 bits in
Status: KX, SX, and UX that enable access to the address space above 32
bits.  With these bits off, an attempt to access these addresses causes an
exception.  So while 32-bit apps have the full 64-bit address space, most of
it is inaccessible to the 32-bit app.

There's a table in Chapter 4 of the MIPS64 Privileged Architecture Spec on
our web page that describes exactly what address references are gated by
what bit.

I notice the original question was about MIPS III.  There were certain early
chips that had problems with access control on the extended segments, so
it's possible that there could be implementation-specific problems.


/gmu
---
Michael Uhler, Chief Technology Officer
MIPS Technologies, Inc.   Email: uhler@mips.com
1225 Charleston Road      Voice:  (650)567-5025   FAX:   (650)567-5225
Mountain View, CA 94043   Mobile: (650)868-6870   Admin: (650)567-5085


> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org 
> [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Daniel 
> Jacobowitz
> Sent: Wednesday, February 01, 2006 8:44 AM
> To: Maciej W. Rozycki
> Cc: Johannes Stezenbach; linux-mips@linux-mips.org
> Subject: Re: gdb vs. gdbserver with -mips3 / 32bitmode userspace
> 
> 
> On Tue, Jan 31, 2006 at 05:36:13PM +0000, Maciej W. Rozycki wrote:
> > On Tue, 31 Jan 2006, Johannes Stezenbach wrote:
> > 
> > > I think (maybe in error ;-), that all binaries compiled 
> for a 32bit 
> > > ABI, but a 64bit ISA, have this flag set, as the kernel 
> will refuse 
> > > to execute 64bt code (i.e. not o32 or n32 ABI). 
> Therefore, shouldn't 
> > > gdb also evaluate this flag when deciding about the ISA register 
> > > size?
> > 
> >  O32 implies 32-bit registers no matter what ISA is specified (while
> > o32/MIPS-III is effectively o32/MIPS-II, o32/MIPS-IV makes 
> a difference), 
> > therefore it's a bug.  You should try sending your proposal to 
> > <gdb-patches@sources.redhat.com> instead.  But I smell the 
> problem is 
> > elsewhere -- mips_isa_regsize() shouldn't be called for the 
> "cooked" 
> > registers and these are ones you should only see under 
> Linux or, as a 
> > matter of fact, any hosted environment.  See 
> mips_register_type() for a 
> > start.
> 
> All of this code is flat-out wrong, as far as I'm concerned.  
> I have a project underway which will fix it, as a nice side effect.
> 
> GDB is trying to do something confusing, but admirable, here. 
>  When you're running on a 64-bit system the full 64 bits are 
> always there: even if the binary only uses half of them (is 
> this true in Linux?  I don't remember if the relevant control 
> bits get fudged, it's been a while; it's definitely true on 
> some other systems).  Thus it's possible for a bogus 
> instruction to corrupt the top half of a register, leading to 
> otherwise inexplicable problems.
> 
> So if the remote stub knows about 64-bit registers, it should 
> report them to GDB, and GDB should accept and display them, 
> and still handle 32-bit frames.  If the remote stub doesn't, 
> then there's no option but to report the 32-bit registers.
> 
> Really, GDB ought to (and soon will I hope) autodetect which 
> ones were sent.
> 
> -- 
> Daniel Jacobowitz
> CodeSourcery
> 
> 

RE: gdb vs. gdbserver with -mips3 / 32bitmode userspace

[Michael Uhler]

Daniel,

The O/S maybe doing something different, but the architecture has 3 bits in
Status: KX, SX, and UX that enable access to the address space above 32
bits.  With these bits off, an attempt to access these addresses causes an
exception.  So while 32-bit apps have the full 64-bit address space, most of
it is inaccessible to the 32-bit app.

There's a table in Chapter 4 of the MIPS64 Privileged Architecture Spec on
our web page that describes exactly what address references are gated by
what bit.

I notice the original question was about MIPS III.  There were certain early
chips that had problems with access control on the extended segments, so
it's possible that there could be implementation-specific problems.


/gmu
---
Michael Uhler, Chief Technology Officer
MIPS Technologies, Inc.   Email: uhler@mips.com
1225 Charleston Road      Voice:  (650)567-5025   FAX:   (650)567-5225
Mountain View, CA 94043   Mobile: (650)868-6870   Admin: (650)567-5085


> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org 
> [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Daniel 
> Jacobowitz
> Sent: Wednesday, February 01, 2006 8:44 AM
> To: Maciej W. Rozycki
> Cc: Johannes Stezenbach; linux-mips@linux-mips.org
> Subject: Re: gdb vs. gdbserver with -mips3 / 32bitmode userspace
> 
> 
> On Tue, Jan 31, 2006 at 05:36:13PM +0000, Maciej W. Rozycki wrote:
> > On Tue, 31 Jan 2006, Johannes Stezenbach wrote:
> > 
> > > I think (maybe in error ;-), that all binaries compiled 
> for a 32bit 
> > > ABI, but a 64bit ISA, have this flag set, as the kernel 
> will refuse 
> > > to execute 64bt code (i.e. not o32 or n32 ABI). 
> Therefore, shouldn't 
> > > gdb also evaluate this flag when deciding about the ISA register 
> > > size?
> > 
> >  O32 implies 32-bit registers no matter what ISA is specified (while
> > o32/MIPS-III is effectively o32/MIPS-II, o32/MIPS-IV makes 
> a difference), 
> > therefore it's a bug.  You should try sending your proposal to 
> > <gdb-patches@sources.redhat.com> instead.  But I smell the 
> problem is 
> > elsewhere -- mips_isa_regsize() shouldn't be called for the 
> "cooked" 
> > registers and these are ones you should only see under 
> Linux or, as a 
> > matter of fact, any hosted environment.  See 
> mips_register_type() for a 
> > start.
> 
> All of this code is flat-out wrong, as far as I'm concerned.  
> I have a project underway which will fix it, as a nice side effect.
> 
> GDB is trying to do something confusing, but admirable, here. 
>  When you're running on a 64-bit system the full 64 bits are 
> always there: even if the binary only uses half of them (is 
> this true in Linux?  I don't remember if the relevant control 
> bits get fudged, it's been a while; it's definitely true on 
> some other systems).  Thus it's possible for a bogus 
> instruction to corrupt the top half of a register, leading to 
> otherwise inexplicable problems.
> 
> So if the remote stub knows about 64-bit registers, it should 
> report them to GDB, and GDB should accept and display them, 
> and still handle 32-bit frames.  If the remote stub doesn't, 
> then there's no option but to report the 32-bit registers.
> 
> Really, GDB ought to (and soon will I hope) autodetect which 
> ones were sent.
> 
> -- 
> Daniel Jacobowitz
> CodeSourcery
> 
> 

Re: gdb vs. gdbserver with -mips3 / 32bitmode userspace

[Johannes Stezenbach]

On Tue, Jan 31, 2006, Johannes Stezenbach wrote:
> On Tue, Jan 31, 2006, Thiemo Seufer wrote:
> > On Tue, Jan 31, 2006 at 07:14:14PM +0100, Johannes Stezenbach wrote:
> > [snip]
> > > Yes, that's why I said I'm confused about mips_isa_regsize() vs.
> > > mips_abi_regsize().
> > > 
> > > mips_abi_regsize() correctly says the register size is 32bit for o32,
> > > but mips_register_type() calls mips_isa_regsize(), not
> > > mips_abi_regsize(). That's why I chose to "fix" mips_isa_regsize().
> > > 
> > > Or should mips_register_type() simply call mips_abi_regsize()?
> > 
> > Without having had a look at the code I think that's the right fix.
> 
> OK, I'll test if that works for me, and post results here

OK, after some testing, the patch below seems to work.

Johannes


--- gdb-6.3/gdb/mips-tdep.c.orig	2004-10-15 09:25:03.000000000 +0200
+++ gdb-6.3/gdb/mips-tdep.c	2006-01-31 20:27:54.000000000 +0100
@@ -716,16 +716,16 @@ mips_register_type (struct gdbarch *gdba
       && (regnum % NUM_REGS) < mips_regnum (current_gdbarch)->fp0 + 32)
     {
       /* The floating-point registers raw, or cooked, always match
-         mips_isa_regsize(), and also map 1:1, byte for byte.  */
+         mips_abi_regsize(), and also map 1:1, byte for byte.  */
       switch (gdbarch_byte_order (gdbarch))
 	{
 	case BFD_ENDIAN_BIG:
-	  if (mips_isa_regsize (gdbarch) == 4)
+	  if (mips_abi_regsize (gdbarch) == 4)
 	    return builtin_type_ieee_single_big;
 	  else
 	    return builtin_type_ieee_double_big;
 	case BFD_ENDIAN_LITTLE:
-	  if (mips_isa_regsize (gdbarch) == 4)
+	  if (mips_abi_regsize (gdbarch) == 4)
 	    return builtin_type_ieee_single_little;
 	  else
 	    return builtin_type_ieee_double_little;
@@ -738,7 +738,7 @@ mips_register_type (struct gdbarch *gdba
     {
       /* The raw or ISA registers.  These are all sized according to
 	 the ISA regsize.  */
-      if (mips_isa_regsize (gdbarch) == 4)
+      if (mips_abi_regsize (gdbarch) == 4)
 	return builtin_type_int32;
       else
 	return builtin_type_int64;

Re: gdb vs. gdbserver with -mips3 / 32bitmode userspace

[Johannes Stezenbach]

On Wed, Feb 01, 2006 at 08:07:01PM +0100, Johannes Stezenbach wrote:
> OK, after some testing, the patch below seems to work.
[snip wrong patch]

I had my mail filters set up wrong I missed some replies which
went into the wrong folder :-(

Sorry about the noise,
Johannes

Re: gdb vs. gdbserver with -mips3 / 32bitmode userspace

[Daniel Jacobowitz]

On Wed, Feb 01, 2006 at 09:26:57AM -0800, Michael Uhler wrote:
> Daniel,
> 
> The O/S maybe doing something different, but the architecture has 3 bits in
> Status: KX, SX, and UX that enable access to the address space above 32
> bits.  With these bits off, an attempt to access these addresses causes an
> exception.  So while 32-bit apps have the full 64-bit address space, most of
> it is inaccessible to the 32-bit app.

That's not actually what I was referring to: there's at least one MIPS
implementation where the results of 32-bit arithmetic operations are
not just architecturally unpredictable but actually wrong if the upper
bits are not properly sign extended (I might be misremembering, but I
think I'm talking about the SB-1).  That's the sort of thing that can
be basically impossible to track down if your debugger doesn't show
you the whole register.

-- 
Daniel Jacobowitz
CodeSourcery

Re: gdb vs. gdbserver with -mips3 / 32bitmode userspace

[Johannes Stezenbach]

On Wed, Feb 01, 2006, Daniel Jacobowitz wrote:
> All of this code is flat-out wrong, as far as I'm concerned.  I have a
> project underway which will fix it, as a nice side effect.
> 
> GDB is trying to do something confusing, but admirable, here.  When
> you're running on a 64-bit system the full 64 bits are always there:
> even if the binary only uses half of them (is this true in Linux?  I
> don't remember if the relevant control bits get fudged, it's been a
> while; it's definitely true on some other systems).  Thus it's possible
> for a bogus instruction to corrupt the top half of a register, leading
> to otherwise inexplicable problems.
> 
> So if the remote stub knows about 64-bit registers, it should report
> them to GDB, and GDB should accept and display them, and still handle
> 32-bit frames.  If the remote stub doesn't, then there's no option but
> to report the 32-bit registers.
> 
> Really, GDB ought to (and soon will I hope) autodetect which ones were
> sent.

If I understand this correctly, gdbserver should check the
register size supported by the OS, and communicate this to gdb?

I'm using a Linux kernel with CONFIG_32BIT, and if I understand
the ptrace interface correctly, the registers as seen through
ptrace are 32bit then, even though the CPU has 64bit registers.

(I have no idea if the cp0 status suggested by others in this
thread reflect CONFIG_32BIT vs. CONFIG_64BIT on Linux.)


Anyway, is a better workaround _now_ for gdb-6.[34] than the patch
to mips_register_type()?


Thanks,
Johannes

Re: gdb vs. gdbserver with -mips3 / 32bitmode userspace

[Ralf Baechle]

On Wed, Feb 01, 2006 at 02:24:04PM -0500, Daniel Jacobowitz wrote:

> > The O/S maybe doing something different, but the architecture has 3 bits in
> > Status: KX, SX, and UX that enable access to the address space above 32
> > bits.  With these bits off, an attempt to access these addresses causes an
> > exception.  So while 32-bit apps have the full 64-bit address space, most of
> > it is inaccessible to the 32-bit app.
> 
> That's not actually what I was referring to: there's at least one MIPS
> implementation where the results of 32-bit arithmetic operations are
> not just architecturally unpredictable but actually wrong if the upper
> bits are not properly sign extended (I might be misremembering, but I
> think I'm talking about the SB-1).  That's the sort of thing that can
> be basically impossible to track down if your debugger doesn't show
> you the whole register.

You were right, that was the SB1 core of the BCM1250 on your Sentosa.  The
behaviour however is legal; the MIPS64 specification states for almost all
32-bit arithmetic instructions that their proper operation is only
guaranteed for properly 64-bit sign-extended operands.

  Ralf

Re: gdb vs. gdbserver with -mips3 / 32bitmode userspace

[Ralf Baechle]

On Wed, Feb 01, 2006 at 08:44:43PM +0100, Johannes Stezenbach wrote:

> If I understand this correctly, gdbserver should check the
> register size supported by the OS, and communicate this to gdb?
> 
> I'm using a Linux kernel with CONFIG_32BIT, and if I understand
> the ptrace interface correctly, the registers as seen through
> ptrace are 32bit then, even though the CPU has 64bit registers.

Correct.  On 32-bit kernels Linux will largely forget about the 64-bitness
of the processor.  User processes will run with 64-bit (UX bit) disabled,
so they're never able to anything 64-bitish.  The kernel will only save
and restore the lower 32-bit of registers, so the upper 32-bit will be
lost.  That means only using the $zero register as 64-bit register is safe
and that's exploited by clear_page().  There are a few place where 64-bit
loads and stores are needed because particular hardware doesn't like being
talked to with 32-bit accesses; those accesses need make sure they're not
interrupted or bad things happen.  See the code for *readq() and write()
in <asm/io.h>.

Ages ago I tried leaving all the 64-bit functionality available as far as
possible even in 32-bit kernels.  It turned out to be example messy and I
was happy to have gotten rid of it, I think in 2.1.14.

> (I have no idea if the cp0 status suggested by others in this
> thread reflect CONFIG_32BIT vs. CONFIG_64BIT on Linux.)

On 32-bit kernels Linux will clear c0_status.kx, c0_status.ux and
c0_status.fr - on hardware were those bits exist at all, that is.

On 64-bit kernels Linux will set c0_status.kx.  It will also always set
c0_status.ux which means 64-bit operations are legal even for 32-bit
processes.  To my knowledge nobody is exploiting that; I guess it could
be exploited for a faster memcpy and similar.  Finally c0_status.fr which
will be set according to the ABI of the process, that is it'll be cleared
for o32 and set for N32 and N64 processes.

  Ralf