I know it’s far off-topic, but I’m quite desperate and it might be that somebody here knows a quick answer.
The trouble is that gdb refuses to execute virtual functions with the message: ‘Could not find virtual table pointer for class “xxx”’ which is quite annoying. I suspect this happens since my platform was upgraded and the gcc version changed from 2.95 to 3.3 for it was working perfectly before. The current gdb version is 5.3. Do I have to use special compiler options beside the usual -g or does gdb needs some special options?
The current gdb version is 6.3. I would not be suprised to learn that 5.3 is too old to understand the virtual tables in gcc 3.3. You should have your
gdb upgraded to match the compiler upgrade.
This is odd, because gdb reports ‘This GDB was configured as “i586-suse-linux”.’ at the beginning. i586-suse-linux is the platform in question. It’s hard to believe that people at Suse bundled the wrong gcc and gdb versions together. I’ve also tried on a slightly newer platform with gdb 6.2.1 installed. Again, the same bad result. Anyway, thanks for the hint.
When looking with nm I don’t find the vtable keyword neither in the object files nor in the libraries. Looks like the virtual tables are not there at all. Does gcc3 need some special option beside -g for producing them?
No gcc3 does not even need the -g option to produce
virtual function tables, they are part of the normal
implementation of virtual function calls.
Did you pipe the output of nm -Bg to c++filt to have
the names demangled? If you do not do that, you
will not see the vtable keyword with a grep. It should
be something like this:
nm -Bg libmycode.a | c++filt | egrep ‘vtable’
It used to be that if all of your virtual functions were
inline, then no vtable would get produced. Since most
compilers worked this way it became a C++ tradition
to make the destructor the first non-inline virtual
function in the class declaration. If it was a simple
class the implementation file often had only the
definition of the virtual destructor, which could even
be empty. This was necessary to force the compiler
to produce a vtable for the class, since the rule was
that the vtable was inserted into the object file
which contained the implentation of the first non-inline
virtual function in the class declaration.
The g++ compiler used to behave this way too, and
something like this may be happening to you, which
is why I have suggested that you examine your
object code to make sure that the vtables are being
produced.
Thanks for the hint. Okay, when demangling the symbols properly I can see the virtual tables are there. Have to be, because most of my virtual functions are non-inlines and also the polymorphism in my program works as expected.
Are the virtual tables sufficient for the debugger or does it need more debugging symbols for using virtual functions? In the gcc documentation different levels and types of debugging information are mentioned.
The different types and levels of debugging information
that you see in the manual are actually mostly historical
artifacts, gdb is really, really old fo software. It supports
debugging formats that were used 20 years ago. The
current formats in use on Linux are ELF and DWARF.
Could it be that the vtables which are needed to perform
the function call you are requesting are not loaded into
the debugger at the time you make your call? This could
happen if your code is linked with shareable libraries and
one of them is not loaded.
You should probably make a very small program, say with
two classes A and B, where B overrides a virtual function
from A, and then call the virtual function from inside the
debugger. You should be able to convince yourself that
everything works correctly with a sufficiently small example.
If it does not, then it will be much easier to figure out what
is wrong.