This is the mail archive of the ecos-devel@sourceware.org mailing list for the eCos 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: Strange __cxa_pure_virtual problem


Bart Veer wrote:
"John" == John Dallaway <john@dallaway.org.uk> writes:


John> Hi Uwe (and Bart)

<snip>

    John> Bart, do you have any ideas why your implementation of
    John> __cxa_pure_virtual() in CYGPKG_INFRA might be ignored?

It is not necessarily being ignored. The eCos version of
__cxa_pure_virtual() ends up in libtarget.a, which is part of the same
linker script GROUP() as libsupc++.a. So strictly speaking the linker
is perfectly at liberty to choose one or the other.

In fact it isn't. Order is still well-defined. Anything else would be a bug.


I believe I've worked out where this problem is coming from. Unresolved symbol searches are not restarted. Which means ld will not return to the start of the library path to look for unresolved symbols - it will just continue from where it already is in the search path at the point the unresolved symbol appears. So something that references __cxa_pure_virtual from somewhere _after_ libtarget.a, won't see the version in libtarget.a. Note this behaviour is not specific to GROUP; it's also true for standard linking.

Normally this isn't an issue for symbols within libtarget.a as the symbols are unique.

I note this could potentially also affect stuff in infra's delete.cxx and memalloc's malloc.cxx definitions of new/delete if CYGFUN_MEMALLOC_MALLOC_CXX_OPERATORS is on. So it's possible we need a more general solution than just for __cxa_pure_virtual().

But back to uSTL, I'm still not clear how Uwe has hit this. I did request the other day for a linker map file, which may shed some light. That request still stands. My guess is that uSTL is referencing some object in libsupc++ which is in turn referencing __cxa_pure_virtual. But I don't get why uSTL is a factor here when building a test like diag_sprintf1, as the presence of uSTL surely hasn't changed how diag_sprintf1 is built has it? Perhaps Uwe could shed some light. The uSTL package CDL doesn't seem to do anything like turn on -fexceptions or -frtti for example, that I've seen.

So we need more information before determining a correct fix (and FAOD, as Bart will know, his workaround would not be appropriate to be checked in).

Jifl
--
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine


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