Re: IA32: printing FP register variables

[Richard Henderson <rth@cygnus.com>]

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 <jimb@cygnus.com>
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: <np4sj8i9pp.fsf@zwingli.cygnus.com>
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 <jimb@cygnus.com>
To: Richard Henderson <rth@cygnus.com>
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: <np3dysi9gh.fsf@zwingli.cygnus.com>
References: <400.931648196@upchuck.cygnus.com> <np908ljwht.fsf@zwingli.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 <jimb@cygnus.com>
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: <np1zeci6tm.fsf@zwingli.cygnus.com>
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 <law@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
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: <np4sj8i9pp.fsf@zwingli.cygnus.com>
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