Re: LRS in STABS

[Jeffrey A Law <law@cygnus.com>]

  In message <npaet1jxf7.fsf@zwingli.cygnus.com>you write:
  > > It would be nice to finally hash through these issues as I'd like to 
  > > contribute Cygnus's LRS code to egcs in the near future.
  > 
  > Tired of doing the merge every month?  :)
It's not so much the merge issues as a desire to get the code available to
more folks.  It's doing neither Cygnus nor egcs any good sitting in just
the Cygnus sources.  Both groups benefit from wider distribution of that code.

  > Is there a reason not to merge what we have now into EGCS, aside from
  > its quirkiness?  It seems to me like it carries the right information.
It certainly needs some cleanup.  The way we find suitable loops for LRS
needs to be using the cfg and code to detect natural loops.  I'm not real
happy with some of the stuff in final & dbxout.

Looking further out, David Miller has been working on a new register allocator
which would do LRS internally, which would make much of the stuff Cygnus did
obsolete (LRS is better handled by building interference graphs during 
allocation and splitting in response to register pressure).

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


  > The drawbacks are:
  > 1) We're inventing a new notation.  But if EGCS doesn't like the
  >    existing LRS notation, I guess it's inevitable.
I wouldn't go quite that far.  How about "I think we can do better" :-)

  > 2) We avoid putting cruft in EGCS, but GDB acquires new complexity,
  >    because it needs to understand both notations, for at least a
  >    while.  Maybe this isn't necessary, since only GnuPRO GCC produces
  >    it, and if someone gets a new GDB, they'll also get a new GCC.
They would get both in lock step.  It would mean objects compiled with
older GnuPro compilers could not be debugged with a newer gdb if they had
any live range splits.  But this is really a Cygnus issue and shouldn't
effect what we do for gdb & gcc.  If it means Cygnus has to keep some
compat code in gdb for a while, we can do that.

  > 3) We're investing effort in what I thought was a dead notation.  We
  >    should be implementing Dwarf2 compression in the linker and
  >    encouraging people to switch, not adding more garbage to STABS.
Yup.  This is one of the biggest reasons to live with the existing stabs
notation and instead spend our time working on getting the dwarf2 range stuff
working which is going to require both gcc & gdb work.

jeff