From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: "Ben Combee" Cc: , Subject: Re: IA32: printing FP register variables Date: Fri, 09 Jul 1999 10:53:00 -0000 Message-id: References: <199907090356.WAA01337@zwingli.cygnus.com> <000d01bec9c2$06f4fdb0$3404010a@metrowerks.com> X-SW-Source: 1999-q3/msg00026.html > 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 don't have an MMX manual handy, but it seems like a much easier case than the FPU, since the registers don't shift around every time you do an operation. > 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. Well, the reason this problem seems hard to me is exactly because the position of items relative to the top of the stack *will* change, whenever you execute instructions like FILD, FDIVP, etc. If they were a constant distance, then we could simply assign register numbers to ST(0) -- ST(7) in the usual way, and everything would work. >From jimb@cygnus.com Fri Jul 09 11:14:00 1999 From: Jim Blandy To: law@cygnus.com Cc: egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: IA32: printing FP register variables Date: Fri, 09 Jul 1999 11:14:00 -0000 Message-id: References: <4264.931496789@upchuck.cygnus.com> X-SW-Source: 1999-q3/msg00027.html Content-length: 1208 STABS's live range splitting notation can certainly do the job correctly, but I wonder whether it can do it efficiently. For every instruction that changes TOP, you have to start a new range for every variable. So the size of debug info is O(number of insns * average number of live variables). Without knowing too much about how the FPU register allocation works, I'd guess that GCC could simply emit a stab after each instruction which changes the depth, whose value is the code address and whose `desc' is the distance from TOP to the base used for register numbering. That is, if we've got an N_RSYM saying that foo lives in ST(2), and we've just seen an N_FPSTACK stab with a value of 3, then we'll look for foo in ST(5). Or change the sign of things as appropriate. This means the size of the debug info is O(number of insns). On the other hand, it's more work to implement in GDB. In either case, GCC needs to be fixed to propagate the register numbers through the stackifier. At that point, if it is straightforward to get GCC to emit LRS info, we could give that a try (no work for me, assuming GDB's LRS code works!). If that's too big, then maybe we could try implementing a depth stab. >From amylaar@cygnus.co.uk Fri Jul 09 11:22:00 1999 From: Joern Rennecke To: jimb@cygnus.com (Jim Blandy) Cc: law@cygnus.com, egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: IA32: printing FP register variables Date: Fri, 09 Jul 1999 11:22:00 -0000 Message-id: <199907091822.TAA31184@phal.cygnus.co.uk> References: X-SW-Source: 1999-q3/msg00028.html Content-length: 494 > STABS's live range splitting notation can certainly do the job > correctly, but I wonder whether it can do it efficiently. For every > instruction that changes TOP, you have to start a new range for every > variable. So the size of debug info is O(number of insns * average > number of live variables). You only have to care about variables that are live in the register stack before or after the operation. So you can use an upper bound of 8. Hence the deubg info is O(number of insns). >From bcombee@metrowerks.com Fri Jul 09 12:33:00 1999 From: "Ben Combee" To: "Jim Blandy" Cc: , Subject: Re: IA32: printing FP register variables Date: Fri, 09 Jul 1999 12:33:00 -0000 Message-id: <014f01beca41$c42b4e50$3404010a@metrowerks.com> References: <199907090356.WAA01337@zwingli.cygnus.com> <000d01bec9c2$06f4fdb0$3404010a@metrowerks.com> X-SW-Source: 1999-q3/msg00029.html Content-length: 1281 > > 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. > > Well, the reason this problem seems hard to me is exactly because the > position of items relative to the top of the stack *will* change, > whenever you execute instructions like FILD, FDIVP, etc. If they were > a constant distance, then we could simply assign register numbers to > ST(0) -- ST(7) in the usual way, and everything would work. I guess an example would help... Consider this code where we have doubles a and b allocated to two spots on the FP stack (excuse the MASM notation... I'm not yet fluent in gas syntax) fld a_value ;; a is at bottom_offset(0) fld b_value ;; b is at bottom_offset(1) fld1 ;; temp with no debug info fadd st2 ;; result of (a + 1) fstp st1 ;; stored into b, pop the temp At each instruction, the invariant that a is 0 from the bottom and b is 1 from the bottom holds. Note, the bottom of the stack can be known by the debugger via scanning the FPU tag word from the TOP element looking for a FP register that is empty. All this info is provided by an FSAVE or FSTENV. -- Ben Combee, x86/Win32/Novell/Linux CompilerWarrior http://www.metrowerks.com/