Re: Bison and C++

[Hans Aberg]

[I removed the address@hidden cc, the topic seems to be not of any
importance for that list.]

At 07:29 -0700 0-12-26, Richard Stallman wrote:
>    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.
>
>M-x gdb in Emacs will do this for you.

Thank you; I will try it out, if I get access to GNU tools (which will
happen when I switch to MacOS X.

If it is the same feature we are speaking about: What I meant is that the
arrow points at the .y source file when stepping around. So one should see
the Bison rules with an arrow.

I have since learnt that this cannot currently be done with the Metrowerks
CodeWarrior (CW) IDE by third party developers, because the format of their
symbolic files are not public.

When a regular C/C++ source is compiled, the CW, apart from the object .o
file, also writes a special .sym file with information for the debugger
about which names should be debugged, their format, and so on, sufficient
for debugging. If I would have implemented the feature I wanted for Bison,
it would have been necessary to directly write a .sym file with the
information about the .y rules.

Perhaps this process can be explained by adding extensions (which is not
the way it is done by the compiler, but what I do here simply to illustrate
the reasoning. So suppose a file <name>.c is compiled, and call the
produced object file <name>.c.o with the ".c" retained, in order to keep
track of its origin. Then, for debugging purposes, one also gets a
<name>.c.sym file which the debugger can use to debug the <name>.c.o file.

Now, with bison I start with a <name>.y file, and get a <name>.c file
(skipping the actual "tab" extension). Now it seems that I should also
somehow produce a <name>.y.sym file, which the debugger uses together with
the <name>.c.sym to debug the final <name>.c.o file. -- I do not see the
actual details, but this is the idea that comes to my mind.

The thing is that if one tries to debug the <name>.c.o file directly, it is
extremely hard, because it just goes around in a very long loop. So it is
hard from that interaction alone to figure out what is going on. -- Somehow
the data that is now available in the debugging files ought to be made
available in interactive debugging.

>I have a feeling this feature [the one discussed below] is not related
>specifically to >Bison,
>but rather a more general issue about C++ (and maybe other languages),
>and supporting the general feature will automatically take care of
>Bison.

Right. So perhaps it should be taken off the bugs-bison list; I leave that
at your discretion.

>    It keeps track of _all_ data relevant for debugging for you.
>    Thus, one never has to write down which variables to debug.
>
>Could you be more specific?  What is the feature you would like?  What
>information is in this data?  I am having trouble understanding what
>you've said.

First, you must understand that I have not used GDB for a few years. When I
used it, I recall one had to use special command to write in the source
file; there were separate debugging source files one had to write . There
is not anything wrong with this system, because it might be needed for
especially tricky debugging.

But the GUI debuggers I used first developed so that one could view a
variable in the GUI debugger by typing its name. But now the CW IDE
debugger has done away with that altogether: All variables are already
present in the debugger and can be reached directly, and no names need to
be typed. One can even select a name in the source code, and hold down the
pointing devise onto it, and all possible information about that variable
is displayed. This is very convenient for most debugging, because it is
fast and very easy access. In non-debugging mode, one can in this way find
the place where any name is declared or defined, so it is very easy to
check out the source codes.

I cannot describe it any better; the best way to figure it out is probably
to get hold of a copy of the IDE, and check it out. The one reason I can
think of using the CW IDE over GNU is that GNU might not have this very
convenient feature.

>     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.
>
>I am not completely sure what this means, since I don't use C++.  But
>it could be an important feature for us to add.  Could you be more
>specific?

C++ has makes available various runtime information (RTTI). C++ has a
single one form of a polymorphic variable, or an object which can change
its type at runtime, namely the polymorphic pointer: If one has a class A
and derives from it a class B, then one can write
  A* ap = new B();
The static type pointer to an  A  named  ap  now points to a dynamically
allocated  B  pointer. It means that in the C++ static typing, this is just
an  ap  pointer, but C++ has mechanism for keeping track of the dynamic
type  B, for example, via "virtual functions", or by using C++ RTTI. (In
C++, in order for A* to qualify as a "polymorphic type", it must contain at
least one "virtual function". If a function name, say "f" is declared
virtual in A, and is called later statcially in the C++ code by "ap->f()",
then if B has a copy that is identical in typing to that of A::f, in
runtime, B::f will be called.)

Now to the debugging: If the debugger only handles C++ static typing, it
will show that  ap  is an  A, and will only display that structure of it
(the names in that class and their values).

But if the debugger handles C++ dynamic data, it will show that the  ap  is
actually a  B, and will show that (the names in that class  B  and their
values).

The CW IDE has a feature that says that it will "attempt" to display the
dynamic type. Once upon the time this feature also worked, and I found it
extremely useful when working with a program using a lot of dynamic data
typing. (However, it does not work currently -- in an upgrade, the
functionality of the feature was lost, and the latest upgrades have not
fixed that bug.)

But as a said, I think this is a very useful debugging feature when
debugging a polymorphic variable: If one produces a program that juggles
such a polymorphic pointer, it is in practise impossible to figure out what
it contains at any given runtime moment. But with the feature, one simply
goes in, and checks its value.

  Hans Aberg