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

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

[Scott Bambrough]

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.

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?

Scott


-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org

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

[Andreas Jaeger]

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

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

[Scott Bambrough]

Andreas Jaeger wrote:
 
> That's desired behaviour.

Then why call __setfpucw in a static binary?  That gives the same program
different behaviour when linked statically and dynamically.  I'd like to know
the rationale behind this difference.

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

Specifically in the ARM case, parts of the gcc testsuite fail.  This is because
gcc generates code for the ARM FPA11 which assumes the AC bit in the FPSR is
set.  The AC bit effects the behaviour of a comparision operation when one of
the operands is a NaN.  I believe by default the hardware has this bit set to
0.  The NWFPE defaults this bit to 0.  I'll have to check what the Acorn FP
emulator does.

The ARM Linux kernel doesn't play with the floating point hardware to my
knowledge.

I can fix this in one of several ways on the ARM:

1) I can modify the kernel, but I doubt if Russell King will accept the patch. 
The kernel can be configured with no FP support, FPA11 support, and support for
FPA11 emulators.  It will also have to support the future VFP unit, and
emulators for that I expect.
2) I can modify the NWFPE, but I'd like to keep it's behaviour consistent with
the actual hardware/support software and the Acorn emulator.  I believe it's
current behaviour is consistent and correct.  I will check though.
3) I can modify GLIBC.  Quite frankly, I think this is the appropriate place for
this.

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

Why would you care to avoid this initialization?  It seems like a one time thing
with very little cost.

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org

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

[Jakub Jelinek]

> > 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.
> 
> Why would you care to avoid this initialization?  It seems like a one time thing
> with very little cost.

The cost is pretty high. It means any program no matter if it will use FPU
or not actually touches the FPU unit. On many machines this means a trap
into the kernel which has to initialize the whole FPU and give it to the
application and on several archs on the next context switch you have no way
to find out nothing else in the FPU state was modified, so you have to save
it.

Cheers,
    Jakub
___________________________________________________________________
Jakub Jelinek | jakub@redhat.com | http://sunsite.mff.cuni.cz/~jj
Linux version 2.3.47 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________

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

[Scott Bambrough]

Jakub Jelinek wrote:
> 
> The cost is pretty high. It means any program no matter if it will use FPU
> or not actually touches the FPU unit. On many machines this means a trap
> into the kernel which has to initialize the whole FPU and give it to the
> application and on several archs on the next context switch you have no way
> to find out nothing else in the FPU state was modified, so you have to save
> it.

Ok, I can see the costs now.  Thanks for the heads up.  I'll look for another
way to fix this.
-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org