[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: It boots!

>Unfortunately, our bash also has the floating point code in it, so it
>won't work (you need bash to call the script to insert the emulator
>module).  I had to install Corel's bash, /lib/ld.so, and
>/lib/libc.so.4* into the Debian partition.  We'll have to figure out
>how to get around this...

Here are a few thoughts about ways in which this could be done.  Maybe it will 
give someone a good idea. :-)

1. Fiddle the kernel so that it can load the fpem.o module itself.  The 2.1 
kmod mechanism may help.  Either you could load it unconditionally from init/
main.c (though this will never get past Linus) or, if you felt a bit more 
sophisticated, you could load it on demand the first time a task tried to 
execute a floating point instruction.

2. Give up on the floating point emulator and use -msoft-float/--without-fp 
instead, either globally or just for bash and init.  The soft float stuff 
isn't currently quite as sophisticated as the emulator (in particular where 
exceptions, rounding modes, etc are concerned) so some work would be needed.

3. Implement the scheme of passing the default floating point control word to 
the libc startup code in the ELF auxilliary vector so that libc can avoid
doing unnecessary wfs calls.  This would be good in any case for performance 
reasons but we will be stuck again if the default fpcw every changes 
(unlikely but...).  Also it won't work for static binaries.  

Maybe this has already been implemented in 2.1 kernels.  The latest glibc 
knows how to use the information if it's passed.

4. Write an alternative version of init-first.c with the floating point stuff 
taken out and find a way to get init and bash to link with it rather than the 
normal version from libc.  This is probably just a case of providing a 
replacement for the _init function and adding it to the final link.

5. Write an open-source floating point emulator and arrange to have it 
actually linked into the kernel rather than as a module (this is how the 386 
version is handled).  The Acorn one is only supplied as a module because of 
copyright problems.

My recommendation would be #3 or #4 in the short term and #5 as the eventual 


Reply to: