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