IA32: printing FP register variables

[Jim Blandy <jimb@cygnus.com>]

This is a question about how GDB should grok code produced by GCC, so
I'm posting it to both lists.

On IA32 processors, how should GDB find the values of variables which
live in floating-point registers?  At the moment, it can't do this
reliably, which must be a royal pain for people doing numeric work.

It's a non-trivial problem.  GCC simply places the variables on the
top of the FP stack, so which physical FP registers receive them
depends on the value of the floating-point stack pointer upon entry to
the function.  And since GCC uses the floating-point stack to hold
temporary values, a variable's offset from the stack pointer changes
as the function executes.

This makes it difficult for GDB to find a variable's value as the
function executes.  In order to find a variable, it needs to know how
many intermediate results are presently above it on the stack.  GCC
knows this, but doesn't give GDB any hints about it in the debugging
info.

What does the register number which GCC emits now mean?  If an N_RSYM
stab has a value of 8, what does that mean?  ST(0)?  When?  Every
variable is ST(0) when it's just been pushed.

Should GCC emit more debug info, to help GDB find variables?

Should GDB derive this info on its own?  It could disassemble the
function, starting from the end of the prologue, and count pushes and
pops, building a table mapping PC values onto stack depths.  (This
assumes that the stack depth is constant at a given PC.)  That would
require no debug info, but would be a pain to implement.
From bcombee@metrowerks.com Thu Jul 08 21:18:00 1999
From: "Ben Combee" <bcombee@metrowerks.com>
To: "Jim Blandy" <jimb@cygnus.com>, <egcs@egcs.cygnus.com>, <gdb@sourceware.cygnus.com>
Subject: Re: IA32: printing FP register variables
Date: Thu, 08 Jul 1999 21:18:00 -0000
Message-id: <000d01bec9c2$06f4fdb0$3404010a@metrowerks.com>
References: <199907090356.WAA01337@zwingli.cygnus.com>
X-SW-Source: 1999-q3/msg00019.html
Content-length: 2585

I have a similar problem as you have, Jim.  I'm working on the CodeWarrior
x86/Linux port, and I have no way to represent that a value has been
allocated to a MMX register.  While CW will also allocate local variables to
floating point stack locations, we don't emit any useful debugging info for
those variables.

I would suggest that we may use a "negative" ST value.  The debugger can
always know the depth of the stack from reading the status registers, so
saying that something was in ST(7) could be interpreted as the top-most
stack item, ST(6) as one below that, and so on.  As long as the relative
position of items on the stack didn't change (this var is always 2 from the
top), this should be OK.

--
Ben Combee, x86/Win32/Novell/Linux CompilerWarrior
http://www.metrowerks.com/
----- Original Message -----
From: Jim Blandy <jimb@cygnus.com>
To: <egcs@egcs.cygnus.com>; <gdb@sourceware.cygnus.com>
Sent: Thursday, July 08, 1999 10:56 PM
Subject: IA32: printing FP register variables


>
> This is a question about how GDB should grok code produced by GCC, so
> I'm posting it to both lists.
>
> On IA32 processors, how should GDB find the values of variables which
> live in floating-point registers?  At the moment, it can't do this
> reliably, which must be a royal pain for people doing numeric work.
>
> It's a non-trivial problem.  GCC simply places the variables on the
> top of the FP stack, so which physical FP registers receive them
> depends on the value of the floating-point stack pointer upon entry to
> the function.  And since GCC uses the floating-point stack to hold
> temporary values, a variable's offset from the stack pointer changes
> as the function executes.
>
> This makes it difficult for GDB to find a variable's value as the
> function executes.  In order to find a variable, it needs to know how
> many intermediate results are presently above it on the stack.  GCC
> knows this, but doesn't give GDB any hints about it in the debugging
> info.
>
> What does the register number which GCC emits now mean?  If an N_RSYM
> stab has a value of 8, what does that mean?  ST(0)?  When?  Every
> variable is ST(0) when it's just been pushed.
>
> Should GCC emit more debug info, to help GDB find variables?
>
> Should GDB derive this info on its own?  It could disassemble the
> function, starting from the end of the prologue, and count pushes and
> pops, building a table mapping PC values onto stack depths.  (This
> assumes that the stack depth is constant at a given PC.)  That would
> require no debug info, but would be a pain to implement.
>