This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: IA32: printing FP register variables
- To: "Ben Combee" <bcombee@metrowerks.com>
- Subject: Re: IA32: printing FP register variables
- From: Jeffrey A Law <law@cygnus.com>
- Date: Thu, 08 Jul 1999 22:59:00 -0600
- cc: "Jim Blandy" <jimb@cygnus.com>, egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
- Reply-To: 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.
> >
>
>