From:	broeker AT physik DOT rwth-aachen DOT de
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Gdb and floating point
Date:	29 Mar 2000 12:37:40 GMT
Organization:	Aachen University of Technology (RWTH)
Lines:	49
Message-ID:	<8bstek$iss$1@nets3.rz.RWTH-Aachen.DE>
References:	<8bikck$54qp1$1 AT fu-berlin DOT de> <38E11218 DOT 31381 DOT 2D63BC AT localhost>
NNTP-Posting-Host:	acp3bf.physik.rwth-aachen.de
X-Trace:	nets3.rz.RWTH-Aachen.DE 954333460 19356 137.226.32.75 (29 Mar 2000 12:37:40 GMT)
X-Complaints-To:	abuse AT rwth-aachen DOT de
NNTP-Posting-Date:	29 Mar 2000 12:37:40 GMT
Originator:	broeker@
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

pavenis AT lanet DOT lv wrote:
> On 25 Mar 2000, at 22:36, Eli Zaretskii wrote:
[...]
>> One thing I *do* know that GDB 4.18 doesn't handle in the DJGPP port
>> is functions that return FP values in FP registers: it displays
>> garbage as the return value for such functions.  GDB 5.0 will corrects
>> this bug.

> Really?

> At least I built gdb-20000327 for DJGPP without problems (thanks Eli 
> for that) but as I tested problem seems to still be there:
> 	I cannot inspect floating pount values in function which return 
> 	double in register (p ..., shows something like X.XXXXXe-312)

That's no what Eli was referring to. He was talking about gdb
displaying the return value, by itself. This happens when you 'call'
the function from gdb, directly, or when you 'finish' it while
stepping through it, IIRC.

The 'print' or 'p' command is different from that. It is the problem
reported by the original poster, Dieter Buerssner.

For that, someone will have to carry out further tests:

1) use '-ggdb3' as the debugging option for gcc. That's supposed to be the
   'ultimate' type of debugging information gcc can generate for use by
   gdb. It may use extensions not supported by other debuggers. I'm not
   sure there is any difference between '-gstabs' and '-ggdb' for our
   platform, where gdb is the only debugger gcc cares about, but it's
   worth a try.

2) Check assembly output to see wether gcc reveals any information about
   floating point variables being moved into and out of registers, to
   the debugger. It's quite hard to interpret all those .stabs manually,
   but it's possible. This should help us find out if gdb or gcc
   is the cause of this problem.

3) Check other Intel platforms (Linux, in particular) to see if this 
   works there. Off the top of my head, I seem to remember it doesn't.
   This may imply that the way FPU registers work makes it hard, or even
   impossible for gcc to consistently inform gdb about where each of
   the variables currently lives.



-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -