This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]