/[bison]/bison/TODO
ViewVC logotype

Diff of /bison/TODO

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.69 by akim, Tue Jun 18 12:39:54 2002 UTC revision 1.70 by akim, Thu Jun 20 12:19:42 2002 UTC
# Line 158  skeleton muscles.      [] Line 158  skeleton muscles.      []
158  ** tests/pure-parser.at []  ** tests/pure-parser.at []
159  New tests.  New tests.
160    
 * Debugging parsers  
   
 From Greg McGary:  
   
 akim demaille <akim.demaille@epita.fr> writes:  
   
 > With great pleasure!  Nonetheless, things which are debatable  
 > (or not, but just `big') should be discuss in `public': something  
 > like help- or bug-bison@gnu.org is just fine.  Jesse and I are there,  
 > but there is also Jim and some other people.  
   
 I have no idea whether it qualifies as big or controversial, so I'll  
 just summarize for you.  I proposed this change years ago and was  
 surprised that it was met with utter indifference!  
   
 This debug feature is for the programs/grammars one develops with  
 bison, not for debugging bison itself.  I find that the YYDEBUG  
 output comes in a very inconvenient format for my purposes.  
 When debugging gcc, for instance, what I want is to see a trace of  
 the sequence of reductions and the line#s for the semantic actions  
 so I can follow what's happening.  Single-step in gdb doesn't cut it  
 because to move from one semantic action to the next takes you through  
 lots of internal machinery of the parser, which is uninteresting.  
   
 The change I made was to the format of the debug output, so that it  
 comes out in the format of C error messages, digestible by emacs  
 compile mode, like so:  
   
 grammar.y:1234: foo: bar(0x123456) baz(0x345678)  
   
 where "foo: bar baz" is the reduction rule, whose semantic action  
 appears on line 1234 of the bison grammar file grammar.y.  The hex  
 numbers on the rhs tokens are the parse-stack values associated with  
 those tokens.  Of course, yytype might be something totally  
 incompatible with that representation, but for the most part, yytype  
 values are single words (scalars or pointers).  In the case of gcc,  
 they're most often pointers to tree nodes.  Come to think of it, the  
 right thing to do is to make the printing of stack values be  
 user-definable.  It would also be useful to include the filename &  
 line# of the file being parsed, but the main filename & line# should  
 continue to be that of grammar.y  
   
 Anyway, this feature has saved my life on numerous occasions.  The way  
 I customarily use it is to first run bison with the traces on, isolate  
 the sequence of reductions that interests me, put those traces in a  
 buffer and force it into compile-mode, then visit each of those lines  
 in the grammar and set breakpoints with C-x SPACE.  Then, I can run  
 again under the control of gdb and stop at each semantic action.  
 With the hex addresses of tree nodes, I can inspect the values  
 associated with any rhs token.  
   
 You like?  
   
161  * input synclines  * input synclines
162  Some users create their foo.y files, and equip them with #line.  Bison  Some users create their foo.y files, and equip them with #line.  Bison
163  should recognize these, and preserve them.  should recognize these, and preserve them.

Legend:
Removed from v.1.69  
changed lines
  Added in v.1.70

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26