Re: LRS in STABS

[Jim Blandy <jimb@cygnus.com>]

>   > 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.