Re: IA32: printing FP register variables

["Ben Combee" <bcombee@metrowerks.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.
>