Re: Major debugging breakage

[law at redhat dot com]

  > > Yea, it was broken before gcc-3.0, so it's been awhile.  I've cc'd Geoff
  > > directly in the hopes that he'll chime in.
  > 
  > I'm sure it's caused by functions-as-trees.
That's my suspicion too.


  > > Every time we parse a token we update LINENO to be equal to SRC_LINENO
  > > (c_lex.c).   LINENO is used to initialize the line numbers in NOTEs
  > > that are used by the debug symbol routines.  The comments in 
cb_line_change
  > > seem to indicate that SRC_LINENO is meant to be used for diagnostic
  > > line numbers.  Maybe that is the root of our problem -- mixing the two
  > > purposes.
  > > 
  > > SRC_LINENO is updated at the start of every non-empty line via
  > > cb_line_change.
  > 
  > Yes, this is most likely the problem.
I don't necessarily think this is the problem -- assuming that SRC_LINENO is
used to output diagnostic messages.

It seems to me that we should have stored the line number into the statement
tree when we first encounter the statement.  We should then extract that
line number from the statement tree when we convert the tree into RTL.

  > What we should be doing, in the case of this example, is producing
  > line numbers for every line.  If the user writes (as I sometimes do)
  > 
  > if ((fd = open ("foo", O_RDONLY)) < 0
  >     || read (fd, &buf, 7) != 7
  >     || read (fd, &bar, 12) != 12)
  >   perror ("problem reading foo");
  > 
  > then it'd be really nice if the debugger could step one line at a
  > time, rather than just doing the whole if condition in one hit.
Agreed -- it would be a significant improvement.  However, I'd settle for
a return to the old behavior right now :-)

jeff