linux-mips
[Top] [All Lists]

Re: Decstation 5000/150 2.3.21 Boot successs

To: Ralf Baechle <ralf@oss.sgi.com>
Subject: Re: Decstation 5000/150 2.3.21 Boot successs
From: "William J. Earl" <wje@cthulhu.engr.sgi.com>
Date: Thu, 6 Jan 2000 17:50:35 -0800 (PST)
Cc: "Kevin D. Kissell" <kevink@mips.com>, Florian Lohoff <flo@rfc822.org>, linux@cthulhu.engr.sgi.com
In-reply-to: <20000107005420.C17537@uni-koblenz.de>
References: <00ef01bf5859$6d11f410$0ceca8c0@satanas.mips.com> <20000107005420.C17537@uni-koblenz.de>
Sender: owner-linuxmips@oss.sgi.com
Ralf Baechle writes:
 > On Thu, Jan 06, 2000 at 04:19:27PM +0100, Kevin D. Kissell wrote:
 > 
 > > >If that's desired, how about providing a syscall which allows to 
 > > >manipulate
 > > >this and possibly other bits?
 > > 
 > > I very much prefer the idea of having exec() to the right thing, so
 > > that 32/32 fpr and o32 ABI programs can be mixed and matched
 > > as appropriate - assuming, of course, that there's sufficient information
 > > in the binary header to do the job!  In practical terms, given that
 > > Linux is a multiuser and multitasking system, a syscall that throws
 > > some sort of global switch could only be safely invoked once
 > > at boot time, and as such offers little advantage over hardwired
 > > kernel code.
 > 
 > I was suggesting such a syscall because embedded people have asked me about
 > making the 32/32 fpr model available to `normal' o32 code.  N32 won't work
 > for them for practical reasons (linker tooo buggy) and 64-bit ABI is
 > unacceptable for size / tlb / cache reasons.

       It could work, but only for very carefully constructed code.
The regular gcc code generation (and matching glibc) for o32 will give
wrong answers with FR=1.  If people really want "o32" with FR=1, then
they need to build yet another binary type, "o32FR1" or some such, with
different code generation rules.  Fundamentally, any code which loads
a double using a pair of lwc1 instructions will get the wrong answer
if FR=1.

 > For the general case you're of course right, exec() should do the right
 > thing.  And modulo the bug we're discussing here the 32-bit kernel already
 > does the right thing to handle the general case.
 > 
 >   Ralf

<Prev in Thread] Current Thread [Next in Thread>