Re: Bison and C++

[Hans Aberg]

At 09.50 -0600 0-10-16, Richard Stallman wrote:
>    One question I think is interesting though, is if one can put info
>into the
>    debug .sym files so that it is possible to GUI debug the original .y
>and .l
>    files.
>
>I don't know what .sym files are--if they are some Macintosh-specific
>thing, then for GNU they are just a side issue of a side issue.

Worse, I think its an inhouse format of the compiler in question.

But any compiler with the ability to create debug files with symbols in
them would have its own debug symbol files. GCC probably has it too, but I
do not have access to GCC right now, so I can't check it out.

>However, GDB understands how to refer to the .y file, because of the
>#line directives that Bison outputs.  If that doesn't work on a
>Macintosh, that would seem to be a bug in their system.

No this works just fine. It is not so much a MacOS thing as the nice GUI
(graphical user interface) of the IDE (integrated development environment),
as the compiler exists also under Windows and UNIX:

When debugging takes place, one sees the original source code in the debug
window (.c file in C), with an arrow pointing at the line where the PC
(program counter) currently is. I recall there is a GUI GDB, but I think
that the difference is that the CW (Metrowerks CodeWarrior) IDE has gone
much further: It keeps track of _all_ data relevant for debugging for you.
Thus, one never has to write down which variables to debug. For debugging
C++ code, I have found it especially important that one can follow the
dynamic type of a polymorphic pointer -- without that feature, it is rather
hopeless trying to debug massively dynamic data. (There are the usual
limitations, variables put into registers or optimized away cannot be well
debugged, and code optimized away cannot be stepped through.) I looked a
little on what is put into those symbol files, and it is mostly references
to C/C++/Pascal etc data structures. So it wouldn't work for Bison.

Now, what one would want to do is to create such a symbol file, where the
output .c code is treated like the assembler code of the object file.
Somehow one should put information about the syntax variables in the .y
file, and their line numbers, so that debugging can take place graphically.
The debugger should display pertinent data, such as how much has been
parsed, perhaps the parsing stack and such. When debugging, instead of just
jumping around in a large matrix

I do not even know if it is possible to it this way. It depends on how
close the relationship is between the .y files and the code in the .c files.

I think though that if it is possible to do such GUI debugging, then the
users would not care much about the _method_ that the parser is using, but
only if it is efficient and such. It will then be possible to make
compiler-compilers which make use of even more complicated algorithms. This
last aspect, is the reason I started to think in these patterns:

There are even more advanced algorithms, basically dynamic in nature, which
then would be more feasible. For example, for Flex, one could make a
translation on the fly, and cache the so obtained tables. One then gets an
algorithm that do not have the translation problems that static algorithms
have, that is, one can avoid that certain regular expressions get an
exponential size/time translation. (There is a remark on this somewhere in
the book by Aho, Sethi, & Ullman.)


  Hans Aberg