This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Problem with fld on i686
- From: John Hedges <john at drystone dot co dot uk>
- To: gdb at sourceware dot cygnus dot com
- Date: Tue, 27 Nov 2001 08:49:36 +0000
- Subject: Problem with fld on i686
I've come across what seems to be a debugger problem with fld. The build is
i686 linux pc. The failing code comes from static_cast<double>(float) which
looks ok.:
(gdb) l
138 __ostream_type&
139 operator<<(float __f)
140 { return this->operator<<(static_cast<double>(__f)); }
(gdb) disassemble
0x80aa350 <_ZNSolsEf>: push %ebp
0x80aa351 <_ZNSolsEf+1>: mov %esp,%ebp
0x80aa353 <_ZNSolsEf+3>: sub $0x8,%esp
0x80aa356 <_ZNSolsEf+6>: sub $0x4,%esp
0x80aa359 <_ZNSolsEf+9>: flds 0xc(%ebp)
0x80aa35c <_ZNSolsEf+12>: lea 0xfffffff8(%esp,1),%esp
0x80aa360 <_ZNSolsEf+16>: fstpl (%esp,1)
0x80aa363 <_ZNSolsEf+19>: pushl 0x8(%ebp)
0x80aa366 <_ZNSolsEf+22>: call 0x80abf00 <_ZNSolsEd>
0x80aa36b <_ZNSolsEf+27>: add $0x10,%esp
0x80aa36e <_ZNSolsEf+30>: mov %ebp,%esp
0x80aa370 <_ZNSolsEf+32>: pop %ebp
0x80aa371 <_ZNSolsEf+33>: ret
The contents of ebp+0x0c (0.8) and registers before the flds instruction:
(gdb) x $ebp+12
0xbf1ff790: 0x3f4ccccd
(gdb) info all
eax 0xbf1ff84c -1088423860
ecx 0x0 0
edx 0xbf1ff764 -1088424092
ebx 0x400ea7f0 1074702320
esp 0xbf1ff778 0xbf1ff778
ebp 0xbf1ff784 0xbf1ff784
esi 0x0 0
edi 0x810b0b8 135311544
eip 0x80aa359 0x80aa359
eflags 0x386 902
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
st0 -0e+4922 (raw 0xffff0000000000000000)
st1 -0e+4922 (raw 0xffff0000000000000000)
st2 -0e+4922 (raw 0xffff0000000000000000)
st3 0 (raw 0x00000000000000000000)
st4 1 (raw 0x3fff8000000000000000)
st5 1 (raw 0x3fff8000000000000000)
st6 3 (raw 0x4000c000000000000000)
st7 1.0909090909090909091204782410677865 (raw
0x3fff8ba2e8ba2e8ba2e9)
fctrl 0x37f 895
fstat 0x0 0
ftag 0x0 0
fiseg 0x23 35
fioff 0x401fa178 1075814776
foseg 0x2b 43
fooff 0x4020b648 1075885640
fop 0x0 0
Registers after flds:
(gdb) si
0x080aa35c 140 { return
this->operator<<(static_cast<double>(__f)); }
(gdb) info all
eax 0xbf1ff84c -1088423860
ecx 0x0 0
edx 0xbf1ff764 -1088424092
ebx 0x400ea7f0 1074702320
esp 0xbf1ff778 0xbf1ff778
ebp 0xbf1ff784 0xbf1ff784
esi 0x0 0
edi 0x810b0b8 135311544
eip 0x80aa35c 0x80aa35c
eflags 0x386 902
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
st0 -nan(0xc000000000000000) (raw 0xffffc000000000000000)
st1 -0e+4922 (raw 0xffff0000000000000000)
st2 -0e+4922 (raw 0xffff0000000000000000)
st3 -0e+4922 (raw 0xffff0000000000000000)
st4 0 (raw 0x00000000000000000000)
st5 1 (raw 0x3fff8000000000000000)
st6 1 (raw 0x3fff8000000000000000)
st7 3 (raw 0x4000c000000000000000)
fctrl 0x37f 895
fstat 0x3a41 14913
ftag 0x0 0
fiseg 0x23 35
fioff 0x80aa359 134914905
foseg 0x2b 43
fooff 0xbf1ff790 -1088424048
fop 0x0 0
The st0 register gets -nan and so this is the result of the static_cast. From
what I can make of fpu docs, the stack overflow bit is set in fstat. The
problem does not occur when run outside the debugger, nor in a minimal test
program.
John