This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]