This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


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

Re: IA32: printing FP register variables



  In message <np673tsfcd.fsf@zwingli.cygnus.com>you write:
  > 
  > > Also when I first did the LRS changes, I thought that you could do
  > > LRS debug information in any debug format, including crippled ones
  > > like COFF, if you were willing to create a new block for every state
  > > change (ie, variable moving from stack to register).
  > 
  > I wonder if it's a good idea to abuse blocks this way.  If the user
  > has a function like this:
  > 
  >     foo ()
  >     {
  >       {
  > 	int a;
  > 	...
  >       }
  >       {
  > 	int a;
  > 	...
  >       }
  >     }
  > 
  > and, while control is in the first inner block, asks the debugger to
  > monitor the value of 'a' as he steps, it would be nice if the debugger
  > could tell that the 'a' in the second block is actually a different
  > variable, and is not the one the user asked about.
Yes.  This is the only design issue I remember anyone raising for
debugging LRS code via block scopes.

It's an issue I'm willing to punt on for now if we could get the block
scope stuff to work though -- the block scope LRS stuff is very portable
if we could deal with the technical issues in the compiler.

One possibility might be to try and use the dwarf2 LRS stuff as the
first option, then the stabs LRS stuff as a secondary option, then fall
back on block scopes for any remaining cases (or if we're trying to avoid
using any stabs extensions).

  > If you use blocks the way you suggest, I'm not sure how GDB could tell
  > the difference between two separate variables with the same name, and
  > a single variable which exists in two blocks created to capture
  > different life ranges.
Without some kind of annotation I do not see a way to deal with this
problem either.

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

jeff


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