|
From: | Satya |
Subject: | Re: Interactive parsing with Bison |
Date: | Mon, 26 Jun 2006 17:31:00 -0500 |
to be able to display positions within each line as well, I think it is just the question of putting the right information in the debugger file format. In the past, perhaps debugger files would have been viewed as becoming to large, but computer space is nowadays is ample: It seems me one should ideally not have to change the source code, in order to do debugging.
Yes, we want to put a lot of information in the debug file. gdb must be modified to understand Bison debug files (and possibly flex debug files ?!); The only change in Bison source will be the task of dumping information in .debug files when requested. regarding the problem of multiple arrows: I think there is more to it... In addition to displaying the position of dot in various rules, we have to display the position of the next lexeme in the test-input file (along with an arrow pointing to the line); that makes it four arrows in 2 windows. One window shows the grammar, the other one shows the test-input being parsed. Perhaps we can highlight the (un)parsed input in a different color? breakpoints: the user must be able to set a breakpoint at a particular token in the test-input; This makes it a little complicated. The input file might have to be pre-scanned by the lexer and broken down into tokens first, so that a token forms one unit (just as a source line forms one unit in gdb); So it finally boils down to 'controlled execution' (of yylex and yyparse functions). Isn't that what gdb does best? Satya.
[Prev in Thread] | Current Thread | [Next in Thread] |