Re: IA32: printing FP register variables

[Jeffrey A Law <law@cygnus.com>]

  In message <000d01bec9c2$06f4fdb0$3404010a@metrowerks.com>you write:
  > 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.
Unfortunately, I believe the relative positions of items does change.

Jim's brought up an interesting problem.

I believe dwarf2 can handle this in a straightforward manner -- it has the
capability to say variable X is in location Y between points A & B and in
location Z between points C & D.

This is more difficult to do with stabs, but possible since Cygnus defined a
set of extensions to describe the same basic concepts.

The more difficult problem is getting information about the state of the
FP regstack  into dwarf2out.c & dbxout.c in a reasonably clean manner.

jeff
dbxout.c 
clean manner 
same mechanisms 


  > 
  > --
  > 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.
  > >
  > 
  >