From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey A Law To: Jim Blandy Cc: egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: IA32: printing FP register variables Date: Thu, 08 Jul 1999 22:12:00 -0000 Message-id: <4264.931496789@upchuck.cygnus.com> References: <199907090356.WAA01337@zwingli.cygnus.com> X-SW-Source: 1999-q3/msg00021.html In message < 199907090356.WAA01337@zwingli.cygnus.com >you write: > 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. To say the least :-) It's not just folks doing numeric work -- it's a pain for those of us who have to analyze bug reports on ia32 which perform FP computations ;-) > 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. I have some guesses about what it might mean ;-) gcc works by initially pretending it has a flat register file with 8 FP regs. It assigns user variables, temporaries, etc to those 8 FP regs. I suspect the number gcc emits corresponds to the index into the flat register file. After allocation is finished, gcc converts the flat register file into a stacked register file. I do not think it tries to update any debug info when converting to a stacked register file. I believe gcc will have to emit more debug info for gdb to be able to find FP variables on the regstack. > 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. Not only would it be a pain, I believe gcc already has this information handy, just not in a good place for emitting debugging symbols. jeff