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>
- Subject: Re: IA32: printing FP register variables
- From: Jim Blandy <jimb@cygnus.com>
- Date: 27 Jul 1999 17:19:54 -0500
- Cc: Robert Lipe <robertlipe@usa.net>, egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com
- References: <19990712204300.K3871@rjlhome.sco.com><10151.931845275@upchuck.cygnus.com><19990714212226.U8492@rjlhome.sco.com><npwvvm0w1o.fsf@zwingli.cygnus.com>
So, here's the question I asked and the response I got from SCO's
compiler fellow (I assume):
Jim> Could you ask your compiler/debugger guys how their compilers
Jim> number the IA32 FP registers? If they assign a fixed register
Jim> number to each ST(i), could you ask them how the debugger finds
Jim> the right ST(i) for a given variable while the stack is being
Jim> pushed and popped? That is, a variable which lives in ST(4) at
Jim> one point will find itself in ST(6) after two FLD instructions,
Jim> and in ST(5) after an FADDP. How would the debugger find the
Jim> variable at each point? Or does the debugger just lose when
Jim> there are intermediate values on the FP stack?
"SCF" == "SCO's compiler fellow", who apparently doesn't want his real
name on public mailing lists:
SCF> Well, I don't have a good answer for you. Our compiler basically
SCF> puts out information for the stack location of an automatic
SCF> floating-point variable. It does not trace the location as it
SCF> moves to the floating-point stack. As you say, the debugger
SCF> "just loses" when there are intermediate values on the FP stack.
SCF> I suppose you could use DWARF2 location lists to track the
SCF> variable with each floating-point push/pop.
So I guess nobody does this right. Heh. I thought so.