> > > This generates floating-point code in kernel, on intel something like:
> > >
> > > fldl .LC25
> > > fmulp %st,%st(1)
> > > fldl .LC26
> > > fdivr %st,%st(1)
> A simpler approach is to use gcc's "-msoft-float" flag. This causes
> all (almost, see the gcc info pages) floating-point operations to be
> emitted as calls to external library routines. Since neither gcc
> nor the linux kernel supply these by default, code using f.p. will
> trigger linker errors. I've tried this on the i386 and it catches
> f.p. use both in the resident part of the kernel and in modules.
>
> If gcc's "-msoft-float" feature is spelled the same on all targets
> then this should probably be moved to the main Makefile.
I don't think that this is a good idea. Ok, kernel uses inline
assembler for saving the state when context switching, but
the initial question was "Is compiling FP-emulation as a module
a good idea (or even possible)".
It's really easy to find FP code in kernel, just look for
double and float types (that's what I've done).
So "-msoft-float" may help to find such cases, but generally using
it for building a normal kernel is IMHO a bit off-topic.
People should check the code and not their compilers. The (rare) cases
where FP-code is in kernel should be fixed (maybe using "-msoft-float"
for dedection) but there is no need to release kernels
with "-msoft-float".
My example, "init=/usr/bin/povray" was not a good one.
Just imagine that {g,}libc people may say: Every program
is a FP-program and what happens if they put floating-point
startup code into __start even if not linked against math.
They can do it (why not ?), and you can't boot at all on
a {3,4}86 SX system with modularized FP-emulation.
--
ciao -
Stefan
Stefan Traby phone: +43-3133-6107-2
Mitterlasznitzstr. 13 fax: +43-3133-6107-9
8302 Nestelbach mailto://stefan@sime.com
Austria
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html