From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com Subject: IA32: printing FP register variables Date: Thu, 08 Jul 1999 20:56:00 -0000 Message-id: <199907090356.WAA01337@zwingli.cygnus.com> X-SW-Source: 1999-q3/msg00018.html 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. >From bcombee@metrowerks.com Thu Jul 08 21:18:00 1999 From: "Ben Combee" To: "Jim Blandy" , , Subject: Re: IA32: printing FP register variables Date: Thu, 08 Jul 1999 21:18:00 -0000 Message-id: <000d01bec9c2$06f4fdb0$3404010a@metrowerks.com> References: <199907090356.WAA01337@zwingli.cygnus.com> X-SW-Source: 1999-q3/msg00019.html Content-length: 2585 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 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. >