Linux: FPU control word not set when __fpu_control == _dl_fpu_control.
Andreas Jaeger
aj@suse.de
Thu Mar 9 10:44:00 GMT 2000
>>>>> Scott Bambrough writes:
> Hi guys,
> I've built a versioned glibc 2.1.3 on a NetWinder, and a kernel with a debug
> printk on WFS (the instruction called when __setfpucw is called). If I build
> static and dynamic test executables (I was using fp-cmp-1.c from the gcc
> testsuite), I only get a printk from WFS when the static executable is run.
That's desired behaviour.
> If I look at sysdeps/unix/sysv/linux/init-first.c, around line 70, there is a
> call to __setfpucw that should be executed. If I look at the the generated .o
> and .os files it is easy to see why it is failing. It doesn't work when
> dynamically linked because of the if statement included when compiling with PIC
> enabled.
> As far as I can tell __fpu_control is almost always equal to _dl_fpu_control.
> __fpu_control is defined and statically initialized in
> sysdeps/generic/fpu_control.c. It is initialized with _FPU_DEFAULT.
> _dl_fpu_control is defined in elf/rtld.c, and statically initialized with
> _FPU_DEFAULT. It is also dynamically initialized from _dl_sysdep_start in
> sysdeps/generic/dl-sysdep.c. The initialization is done if the flag AT_FPUCW is
> in the the headers in the executable. The value used is taken from the
> executable as well.
> This doesn't seem to be an ARM specific problem, but a Linux specific one. Does
> anyone else see the same thing on other platforms?
What exactly is your problem? AFAIK everything works as expected. We
don't need to call __setfpucw in allmost all cases since the kernel
will initialize the FPU to the correct value.
For static binaries, we don't get AT_FPUCW and therefore always call
__setfpucw. But for shared binaries we can be clever and avoid the
initilisation.
Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.rhein-neckar.de
More information about the Libc-hacker
mailing list