This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

LRS in STABS



>   > The STABS LRS stuff, while quirky, doesn't have this problem.
> If you had the opportunity to redesign the stabs LRS stuff, what would you
> recommend?  One possibility would be to try and model it strictly like
> ELF works.  I do not know how feasible that would be.
> 
> 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?  :)

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.

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.

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]