* Problem with fld on i686
2001-11-27 0:53 Problem with fld on i686 John Hedges
@ 2001-11-16 13:40 ` John Hedges
2001-11-16 14:55 ` Eli Zaretskii
1 sibling, 0 replies; 7+ messages in thread
From: John Hedges @ 2001-11-16 13:40 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Problem with fld on i686
2001-11-27 0:53 Problem with fld on i686 John Hedges
2001-11-16 13:40 ` John Hedges
@ 2001-11-16 14:55 ` Eli Zaretskii
2001-11-17 5:39 ` John Hedges
2001-11-27 3:19 ` Eli Zaretskii
1 sibling, 2 replies; 7+ messages in thread
From: Eli Zaretskii @ 2001-11-16 14:55 UTC (permalink / raw)
To: John Hedges; +Cc: gdb
On Tue, 27 Nov 2001, John Hedges wrote:
> The st0 register gets -nan and so this is the result of the static_cast.
I don't get it: are you saying that the disassembly shows incorrect
code? If the code is correct, what does this have to do with the
source code (static_cast etc.) from which the assembly instructions
were produced?
If the code _is_ correct (I think it is), but the results aren't, then
the fact that static_cast was used in the C++ program is irrelevant,
right?
> The problem does not occur when run outside the debugger, nor in a
> minimal test program.
This suggests that perhaps the FPU state is not saved/restored correctly
across task switches. What OS is that? Can you try a different version
of the same OS, or some similar but not identical OS?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Problem with fld on i686
2001-11-16 14:55 ` Eli Zaretskii
@ 2001-11-17 5:39 ` John Hedges
2001-11-18 10:57 ` Andrew Cagney
2001-11-27 3:19 ` Eli Zaretskii
1 sibling, 1 reply; 7+ messages in thread
From: John Hedges @ 2001-11-17 5:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb
On Tuesday 27 Nov 2001 11:18 am, Eli Zaretskii wrote:
> If the code _is_ correct (I think it is), but the results aren't, then
> the fact that static_cast was used in the C++ program is irrelevant,
> right?
Correct - static_cast is irrelevant if we assume it compiled correctly. The
disassembly looks ok to me too but I'm no asm expert.
> > The problem does not occur when run outside the debugger, nor in a
> > minimal test program.
>
> This suggests that perhaps the FPU state is not saved/restored correctly
> across task switches. What OS is that? Can you try a different version
> of the same OS, or some similar but not identical OS?
OS is Linux 2.2.14-5.0. Problem does not occur with Linux 2.2.16 on a
different (but stil i686) box.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Problem with fld on i686
2001-11-17 5:39 ` John Hedges
@ 2001-11-18 10:57 ` Andrew Cagney
2001-11-27 15:04 ` Andrew Cagney
0 siblings, 1 reply; 7+ messages in thread
From: Andrew Cagney @ 2001-11-18 10:57 UTC (permalink / raw)
To: John Hedges; +Cc: Eli Zaretskii, gdb
> On Tuesday 27 Nov 2001 11:18 am, Eli Zaretskii wrote:
> OS is Linux 2.2.14-5.0. Problem does not occur with Linux 2.2.16 on a
> different (but stil i686) box.
A feeling of deja-vu. I'm pretty sure this is a glibc/kernel problem.
Andrew
^ permalink raw reply [flat|nested] 7+ messages in thread
* Problem with fld on i686
@ 2001-11-27 0:53 John Hedges
2001-11-16 13:40 ` John Hedges
2001-11-16 14:55 ` Eli Zaretskii
0 siblings, 2 replies; 7+ messages in thread
From: John Hedges @ 2001-11-27 0:53 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Problem with fld on i686
2001-11-16 14:55 ` Eli Zaretskii
2001-11-17 5:39 ` John Hedges
@ 2001-11-27 3:19 ` Eli Zaretskii
1 sibling, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2001-11-27 3:19 UTC (permalink / raw)
To: John Hedges; +Cc: gdb
On Tue, 27 Nov 2001, John Hedges wrote:
> The st0 register gets -nan and so this is the result of the static_cast.
I don't get it: are you saying that the disassembly shows incorrect
code? If the code is correct, what does this have to do with the
source code (static_cast etc.) from which the assembly instructions
were produced?
If the code _is_ correct (I think it is), but the results aren't, then
the fact that static_cast was used in the C++ program is irrelevant,
right?
> The problem does not occur when run outside the debugger, nor in a
> minimal test program.
This suggests that perhaps the FPU state is not saved/restored correctly
across task switches. What OS is that? Can you try a different version
of the same OS, or some similar but not identical OS?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Problem with fld on i686
2001-11-18 10:57 ` Andrew Cagney
@ 2001-11-27 15:04 ` Andrew Cagney
0 siblings, 0 replies; 7+ messages in thread
From: Andrew Cagney @ 2001-11-27 15:04 UTC (permalink / raw)
To: John Hedges; +Cc: Eli Zaretskii, gdb
> On Tuesday 27 Nov 2001 11:18 am, Eli Zaretskii wrote:
> OS is Linux 2.2.14-5.0. Problem does not occur with Linux 2.2.16 on a
> different (but stil i686) box.
A feeling of deja-vu. I'm pretty sure this is a glibc/kernel problem.
Andrew
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2001-11-27 23:04 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-11-27 0:53 Problem with fld on i686 John Hedges
2001-11-16 13:40 ` John Hedges
2001-11-16 14:55 ` Eli Zaretskii
2001-11-17 5:39 ` John Hedges
2001-11-18 10:57 ` Andrew Cagney
2001-11-27 15:04 ` Andrew Cagney
2001-11-27 3:19 ` Eli Zaretskii
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox