From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Henderson To: Jim Blandy Cc: law@cygnus.com, egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: IA32: printing FP register variables Date: Mon, 12 Jul 1999 19:40:00 -0000 Message-id: <19990712193944.A28644@cygnus.com> References: <400.931648196@upchuck.cygnus.com> X-SW-Source: 1999-q3/msg00061.html On Mon, Jul 12, 1999 at 06:09:50PM -0500, Jim Blandy wrote: > If GDB can find the base of the FP stack reliably, using the method > that Ben Combee suggests, then we don't need LRS at all to describe > variables' homes. If we simply number the FP registers relative to > the base of the FP stack, their names won't change as insns push and > pop FP values. You can find the base of the stack, it's true. But that does you no good whatsoever. Consider the following sequence: (set (reg f0) (add (reg f0) (reg f1))) (set (reg f2) (add (reg f2) (reg f3))) Assuming no register deaths, so there's no popping to add to the confusion, this will ultimately get transformed to fadd %st(1) fxch %st(2) fadd %st(3) Since there's no popping, the base of the FP stack has not changed. However, f2 and f0 were swapped, so that f2 would be at the top of the stack, so that we can perform the second operation. That's not to say that you can't use the FP base to eliminate the need to encode the pushes and pops into the debug information, but you can't get away from bazillions of live ranges. r~ >From jimb@cygnus.com Tue Jul 13 13:19:00 1999 From: Jim Blandy To: law@cygnus.com Cc: egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: LRS in STABS Date: Tue, 13 Jul 1999 13:19:00 -0000 Message-id: References: <9101.931821781@upchuck.cygnus.com> X-SW-Source: 1999-q3/msg00062.html Content-length: 1850 > > I would create a new stab type, N_NEWHOME; you put as many of these as > > needed after an N_[RLP]SYM. I'd use the value of the stab to indicate > > the beginning of the range, perhaps put the length of the range in its > > desc, and encode the variable's new home in the name. > > > > STABS encodes a variable's home in the stab's type and value. There's > > no prior art saying how to put the variable's home in a symbol name. > > But there are really only a few kinds of locations GDB can handle > > anyway, so this isn't too hard. > > > > The value of an N_NEWHOME stab should be relative to the function > > start, to avoid creating relocs. > > > > # The function foo gets x as a parameter on the stack at fp+4. > > # From .LR3 to .LR5, it lives in register 2. > > # From .LR6 to .LR7, it lives in register 8. > > .stabs "x:p1",N_PSYM,0,0,4 > > .stabs "r2",N_NEWHOME,0,.LR5-.LR3,.LR3-foo > > .stabs "r8",N_NEWHOME,0,.LR7-.LR6,.LR6-foo > > > > That seems much simpler than what's described in gdb/doc/LRS. > Seems reasonable to me. It does assume that we know the labels for the > ranges potentially before we actually emit code which can be a problem. Hmm. Stabs for locals are emitted after all the function's code, so those should be okay, right? So formal parameters are the real problem, since their stabs are emitted at the top of the function. However, GCC emits two stabs for each parameter --- one for the DECL_INCOMING_RTL, and then one for the real RTL. (This is the "two stabs for one argument" behavior we discussed before.) And the latter is emitted at the end of the function. So if emit the LRS info after the latter, interior stab (which is the one GDB uses for finding the variable's value anyway, except for backtraces, ugh), then you should already know the labels. >From jimb@cygnus.com Tue Jul 13 13:25:00 1999 From: Jim Blandy To: Richard Henderson Cc: law@cygnus.com, egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: IA32: printing FP register variables Date: Tue, 13 Jul 1999 13:25:00 -0000 Message-id: References: <400.931648196@upchuck.cygnus.com> <19990712193944.A28644@cygnus.com> X-SW-Source: 1999-q3/msg00063.html Content-length: 990 > Assuming no register deaths, so there's no popping to add to the > confusion, this will ultimately get transformed to > > fadd %st(1) > fxch %st(2) > fadd %st(3) > > Since there's no popping, the base of the FP stack has not changed. > However, f2 and f0 were swapped, so that f2 would be at the top of > the stack, so that we can perform the second operation. > > That's not to say that you can't use the FP base to eliminate the > need to encode the pushes and pops into the debug information, but > you can't get away from bazillions of live ranges. If you don't know the base of the FP stack, you have to start a new range at each push, pop, or exchange. If you do know the base, you only need to start a new range at an exchange. So you're right --- the design of the IA32 FPU requires that variables change homes pretty frequently. So LRS is necessary. But numbering registers relative to the FP stack base will still reduce the number of ranges substantially, won't it? >From jimb@cygnus.com Tue Jul 13 14:22:00 1999 From: Jim Blandy To: egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: IA32: printing FP register variables Date: Tue, 13 Jul 1999 14:22:00 -0000 Message-id: References: <9500.931826533@upchuck.cygnus.com> X-SW-Source: 1999-q3/msg00064.html Content-length: 882 I hope that I'm not mixing up my priorities by worrying about debug size. But since a register numbering is a matter of public protocol, it will be more trouble to change it later than to make a good choice now. There are only three possible numberings that make any sense: physical, top-relative, or base-relative. Physical is not possible, since the compiler doesn't know the value of TOP at function entry. top-relative is, I think we all agree, the least stable of all possible orderings. So base-relative is what we have left. We will still require LRS info in almost every case, but it's better than the alternatives. If GCC will have trouble generating base-relative register numbers (if, for example, regstack has no concept of the FP stack base), then that would tip the scales. If someone can find an i386 STABS system that uses another numbering, that would too. >From law@cygnus.com Tue Jul 13 15:45:00 1999 From: Jeffrey A Law To: Jim Blandy Cc: egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: LRS in STABS Date: Tue, 13 Jul 1999 15:45:00 -0000 Message-id: <12472.931905804@upchuck.cygnus.com> References: X-SW-Source: 1999-q3/msg00065.html Content-length: 687 In message < np4sj8i9pp.fsf@zwingli.cygnus.com >you write: > Hmm. Stabs for locals are emitted after all the function's code, so > those should be okay, right? So formal parameters are the real > problem, since their stabs are emitted at the top of the function. Parameters can appear before or after the function body depending on what particular port you are using. > However, GCC emits two stabs for each parameter --- one for the > DECL_INCOMING_RTL, and then one for the real RTL. (This is the "two > stabs for one argument" behavior we discussed before.) I'm not sure this is entirely correct. Particularly for parameters which are passed in registers. jeff