linux-mips
[Top] [All Lists]

Re: r4600 flag

To: "John D. Davis" <johnd@Stanford.EDU>
Subject: Re: r4600 flag
From: Ralf Baechle <ralf@oss.sgi.com>
Date: Thu, 2 Aug 2001 13:54:56 +0200
Cc: Carsten Langgaard <carstenl@mips.com>, SGI MIPS list <linux-mips@oss.sgi.com>
In-reply-to: <Pine.GSO.4.31.0107310824430.28499-100000@epic8.Stanford.EDU>; from johnd@Stanford.EDU on Tue, Jul 31, 2001 at 08:29:12AM -0700
References: <3B66B4E6.70B80D21@mips.com> <Pine.GSO.4.31.0107310824430.28499-100000@epic8.Stanford.EDU>
Sender: owner-linux-mips@oss.sgi.com
User-agent: Mutt/1.2.5i
On Tue, Jul 31, 2001 at 08:29:12AM -0700, John D. Davis wrote:

> Looking at the system map from the generic build of 2.4.3, it looks like
> the code is 64 bit.  The upper 32 bits are "f" instead of 0.

No.  Sign extended, that is bit 31 is copied into bits 32 to 63.

> I built it > using the R4600 flag.  This differs from the system map for
> 2.4.0-test9 where the upper 32 bits are 0.

No.  Different binutils.  Older binutils did zero extend 32-bit addresses
to 64-bit addresses in the objdump output which is wrong.

> For the indy, do I specify mips2 to generate 32 bit code?

-mips2 :-)

For the kernel we use a few 64-bit instructions on the Indy though.  These
are carefully chosen such that nothing go wrong like exceptions corrupting
the upper 32-bit of a register.

> objdump says it is ELF32, but it doesn't look like that.  I would like to
> generate 32bit.

ELF is an object format.  Nothing prevents you from putting 64-bit code into
a 32-bit ELF file and vice versa.  You just need to be careful.

  Ralf

<Prev in Thread] Current Thread [Next in Thread>
  • Re: r4600 flag, Ralf Baechle <=