Re: Linux: FPU control word not set when __fpu_control == _dl_fpu_control.

[Andreas Jaeger <aj at suse dot de>]

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