call-graphs arcs break in shared-library "non-virtual thunk"

[<sta...@bi...>]

Hello,

I'm using 'oprofile' oprofile-0.9.4-15.el5.centos
with the latest CentOS 5.7 debug kernel to profile
an 'x86_64' application that dynamically loads
shared libraries.  Also profiling on SLES 10.

Have it generally working.

However call-arcs are breaking in some glue
code that exists between the program and the
shared libraries.

In the 'opreport' output it's clear that the
stack traceback does not pass through a C++
abstract-base call-interface standing between
executable files.  The glue code is listed as

   non-virtual thunk to

before the target function name.  The code is
optimized with either -O2 or -O3, but the
-fno-omit-frame-pointer switch is present
for all compile and link steps.

The link steps had an -O2 in them, but removing
this produces byte-for-byte identical 
binaries.  The 'gcc' command is used when
invoking 'ld'.

Have read though much of the 'ld' command
line documentation and don't see anything
else that would appear to be of help.
I suspect this code is being generated by
'ld' rather than 'gcc', but am not 100% sure.

The call-arcs for simple C-style calls traverse
shared library boundaries with no problem.
Call-arcs for virtual function calls within
images are complete as well.  The issue is
specific to C++ virtual function calls
where the caller is in one image file
and the callee is in a different image.

Any insight into what is happening and/or
what might be done to eliminate the broken
arcs would be greatly appreciated.

Thanks