This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: I would like to contribute
- To: regan_russell at hotmail dot com, gcc at gcc dot gnu dot org
- Subject: Re: I would like to contribute
- From: russ at amc dot com (Russell Browne)
- Date: Fri, 30 Jun 2000 11:50:00 -0700
Regan Russell wrote:
> Hi, I would like to contribute to gcc.
> I would like you to suggest a small project
> otherwise, I will look for the simplest
> problem in the bug list and investigate it.
Here is a suggestion I have contemplated making for several years.
When a C++ destructor is called, the destructor sets the vtable for
the object under destruction to the vtable for the destructor's class,
so that any virtual function calls go to that class's function rather
than that for a subclass that has now been destroyed.
This can be useful information when debugging if one is using a debugger
such as GDB or UPS that shows the vtable symbolically; if the vtable
shows that the class for an object is the base class of what it
ought to be the most likely cause is that you are looking at an object
that has been destroyed. But this debugging trick does not work if the
object you are looking at is already supposed to be of either the base class
or a subclass.
Now my suggestion: When compiled with debugging and without optimization,
the final step in a destructor for a base class, or for a class whose base
class does not have virtual functions, should be to set the vtable to a
distinctive value. Possible values might be 0, 0xdeadbeaf, or to a symbol
that demangles to something like "destoyed object vtable". If the last
approach, which I like best, is taken, implement such a vtable with the
first 100 or so entries going to a function that prints a message to
stderr and aborts.
Russ Browne
Applied MicroSystems Corp.