Re: arm-pe: Multiple inheritance problem w/C++

[Ian Lance Taylor <ian at airs dot com>]

"Craig A. Vanderborgh" <craigv@voxware.com> writes:

> We have discovered a bad problem with binutils configured for
> arm-wince-pe on an x86linux host.  We have been able to partially
> diagnose this problem, but we really need the help of the experts this
> time.
> 
> The problem is this: in the case where a class has multiple inheritance,
> the vtables seem to be messed up.  The test case below shows that the
> vtable offset of the pure virtual method in DOMImplementationSource is
> used instead of the offset in DOMImplementationImpl, and then applied to
> the Impl vtable.  This breaks C++ programs of any complexity, and seems
> to permeate GNU ld versions 2.11.2, 2.13.9, and even the latest
> snapshot, at least for the arm-pe configuration.

I don't really see how this could be a binutils issue.  The vtables
are created by the compiler.  The linker does nothing special with
vtables, except perhaps in the special case of garbage collection.

Are you using garbage collection (the --gc-sections option)?  If not,
I don't see how this could be a linker problem.

> We have determined that this is not a compiler issue; objects compiled
> with our arm-wince-pe-gcc and linked elsewhere seem to work without
> exhibiting this problem.  We have set our testing up so that both links
> (on the 2 different platforms) receive identical input for all objects
> and libraries. Thus, this is apparently a linker issue.

What do you mean by ``linked elsewhere?''  What is the other linker
you are using?

It's possible that there is a linker problem, and that multiple
inheritance somehow triggers it.  But I don't see how the problem
could actually be multiple inheritance.  It's possible that there is
some relocation type which the linker does not handle correctly, and
that your source code only happens to use that relocation type when
doing multiple inheritance.  It's unlikely, but possible.

Can you expand your test case by including the precise commands you
use to recreate the problem?  Can you indicate what is wrong in the
executable by pointing to the precise area of code which is incorrect
in the linker output?  Can you indicate what that area of code looks
like when ``linked elsewhere?''

Ian