From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey A Law To: "Ben Combee" Cc: "Jim Blandy" , egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: IA32: printing FP register variables Date: Thu, 08 Jul 1999 22:04:00 -0000 Message-id: <4220.931496340@upchuck.cygnus.com> References: <000d01bec9c2$06f4fdb0$3404010a@metrowerks.com> X-SW-Source: 1999-q3/msg00020.html 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 > To: ; > 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. > > > >