This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: arm-pe: Multiple inheritance problem w/C++
- From: "Craig A. Vanderborgh" <craigv at voxware dot com>
- To: Ian Lance Taylor <ian at airs dot com>
- Cc: binutils at sources dot redhat dot com
- Date: 26 May 2003 11:33:02 -0600
- Subject: Re: arm-pe: Multiple inheritance problem w/C++
- References: <m3wugfq3gu.fsf@gossamer.airs.com>
On Sat, 2003-05-24 at 18:23, Ian Lance Taylor wrote:
> "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.
>
Ian, thank you very much for your thoughtful reply. We really
appreciate it because we know that this is the worst kind of problem to
have to deal with.
Apparently the problem resides in bfd/coff-arm.c. Another fellow
arm-wince-pe sufferer pointed this out (at about line 237, coff-arm.c):
#ifdef ARM_WINCE
/* MS ARM-CE makes the reloc relative to the opcode's pc, not
the next opcode's pc, so is off by one. */
#if 0 /* This appears to have been true for WINCE 2.0, but it is not
true for WINCE 3.0. */
if (howto->pc_relative && !info->relocateable)
addend -= 8;
#endif
#endif
/* If we are doing a relocateable link, then we can just ignore
a PC relative reloc that is pcrel_offset. It will already
have the correct value. If this is not a relocateable link,
then we should ignore the symbol value. */
if (howto->pc_relative && howto->pcrel_offset)
{
if (info->relocateable)
continue;
/* FIXME - it is not clear which targets need this next test
and which do not. It is known that it is needed for the
VxWorks and EPOC-PE targets, but it is also known that it
was supressed for other ARM targets. This ought to be
sorted out one day. */
#if ARM_COFF_BUGFIX
/* We must not ignore the symbol value. If the symbol is
within the same section, the relocation should have already
been fixed, but if it is not, we'll be handed a reloc into
the beginning of the symbol's section, so we must not
cancel
out the symbol's value, otherwise we'll be adding it in
twice. */
if (sym != NULL && sym->n_scnum != 0)
addend += sym->n_value;
#endif
Turning on ARM_COFF_BUGFIX corrects the C++ problem as demonstrated by
CastTest. So yes, this is apparently a linker problem - via bfd.
This brings up the larger question - what can we (that is us, at this
end..) to to help facilitate getting arm-wince-pe binutils fully
operational? It is clear that the maintainers have little interest in
Wince. I can't say I blame them. But we are interested (and have to
be!!), and maybe we could help out somehow and get these kinds of
problems found and fixed...
We would be willing to run the testsuite. But on wince, we are unsure
how you would even do it. Is there a way that we could set up the
testsuite so that the tests could be run under the arm-wince-pe
simulator? Can we submit patches somewhere that someone will pay
attention to? We would welcome any advice you might have..
Thanks,
craig vanderborgh
voxware incorporated
> > 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