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.

References between stabs are messy.  If we can use the stab ordering
to convey the same information, then we avoid a lot of hair.

Can you assign label numbers when you generate the stabs, and then use
that info when you emit the labels?  Why must the info flow from the
label emitter to the stabs emitter, and not the other way around?

I assume we're emitting a separate class of labels for LRS info.  The
assembler won't generate any relocs for them, so this is okay, right?