This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: IA32: printing FP register variables
- To: "Jim Blandy" <jimb@cygnus.com>, <egcs@egcs.cygnus.com>, <gdb@sourceware.cygnus.com>
- Subject: Re: IA32: printing FP register variables
- From: "Ben Combee" <bcombee@metrowerks.com>
- Date: Thu, 8 Jul 1999 23:17:58 -0500
- Organization: Metrowerks
- References: <199907090356.WAA01337@zwingli.cygnus.com>
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.
>