This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: I would like to contribute


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]