location of unresolved virtual functions

[Nathan Sidwell]

Hi,
the gnu linker gives nice error messages about unresolved symbols of
the form,
file.o: In function `whatever'
file.cc:<line>: undefined reference to `wibble'

However, when this is a class's vtable and `wibble' is a virtual
function you've forgotton to define, the line number and file are
random, and the `in function' indicates the type_info function.
I've attached a test case which you can compile and link. The
actual linker error depends on whether you have debugging enabled,
and what optimization level chosen. Here is a session log

nathan@manao:540>uname -a
SunOS manao 5.6 Generic_105181-03 sun4u sparc SUNW,Ultra-5_10

nathan@manao:541>ss-g++ -v
Reading specs from /home/staff/nathan/solaris/local/sparc-SunOS_5/lib/gcc-lib/sparc-sun-solaris2.6/egcs-2.92.29/specs
gcc version egcs-2.92.29 19981213 (gcc2 ss-980609 experimental)

nathan@manao:542>ss-g++ vtablediag.ii       
/var/tmp/ccSH758g.o(.gnu.linkonce.d._vt.1A+0x14): undefined reference to `A::Fn(void)'
collect2: ld returned 1 exit status

nathan@manao:543>ss-g++ vtablediag.ii -g
/var/tmp/ccsjjDtt.o: In function `A type_info function':
/home/staff/nathan/solaris/egcs/bugs/vtablediag.ii:10: undefined reference to `A::Fn(void)'
collect2: ld returned 1 exit status

nathan@manao:544>ss-g++ vtablediag.ii -g -O2
/var/tmp/ccNJzk82.o: In function `A::~A(void)':
/home/staff/nathan/solaris/egcs/bugs/vtablediag.ii:11: undefined reference to `A::Fn(void)'
collect2: ld returned 1 exit status

The no debug info case, clues me in that it's a vtable, by the label
name. The -g cases change the location depending on what previous
function the compiler's managed to optimize away. I can live with the
first case, but the -g cases are confusing -- if you're going to give some
one a source location you'd better make it a sensible one. For this
example, the source location is one of the members of A, but that
needn't be the case. I've got examples of it being some utterly
unconnected function.

What I think is happening is that when g++ outputs a vtable, it does
not output any stabs to indicate a source code position. Hence the
linker just uses the last output function location. This can be a
global dtor, ctor or inline function which needs a body. IMHO a
sensible location for the vtable would be the location of the
class definition. An even better location would be, for each virtual
function in the vtable, to indicate where the declaration of the
virtual function was.

Thus it'd be nice if the linker diagnostic was (something like),
ccNJzk82.o: In function `A::virtual function table':
vtablediag.ii:6: undefined reference to `A::Fn(void)'

I grovelled around in the compiler's vtable output code, but it wasn't
obvious how to get this done. The vtable ends up as a normal VAR_DECL
node, so it'd be nice to emit an appropriate stab for this. I'm not
sure of the correct order to emit the assembly label & stab (which
stab?).

nathan

-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
      You can up the bandwidth, but you can't up the speed of light      
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk