From: Jonathan Larmour <jifl@jifvik.org>
To: uwe.kindler@cetoni.de
Cc: Bart Veer <bartv@ecoscentric.com>, ecos-devel@sourceware.org
Subject: Re: Strange __cxa_pure_virtual problem
Date: Wed, 12 Aug 2009 01:34:00 -0000 [thread overview]
Message-ID: <4A821C19.3020407@jifvik.org> (raw)
In-Reply-To: <pnocqrd9or.fsf@delenn.bartv.net>
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
next prev parent reply other threads:[~2009-08-12 1:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-07 11:35 cetoni GmbH - Uwe Kindler
2009-08-07 12:04 ` John Dallaway
2009-08-07 13:40 ` Bart Veer
2009-08-07 15:08 ` John Dallaway
2009-08-07 15:42 ` Bart Veer
2009-08-11 9:05 ` Daniel Néri
2009-08-07 16:31 ` Sergei Gavrikov
2009-08-12 1:34 ` Jonathan Larmour [this message]
-- strict thread matches above, loose matches on Subject: below --
2009-08-19 14:35 cetoni GmbH - Uwe Kindler
2009-08-19 16:05 ` John Dallaway
2009-08-21 14:55 ` Bart Veer
2009-08-12 17:49 Uwe Kindler
2009-08-12 19:07 ` Bart Veer
2009-08-13 8:00 ` Uwe Kindler
2009-08-19 10:37 ` Bart Veer
[not found] <4A827EDC.3030004@cetoni.de>
2009-08-12 14:15 ` Jonathan Larmour
2009-08-12 9:10 cetoni GmbH - Uwe Kindler
2009-08-08 6:04 Uwe Kindler
2009-08-05 18:55 Uwe Kindler
2009-08-07 9:35 ` John Dallaway
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A821C19.3020407@jifvik.org \
--to=jifl@jifvik.org \
--cc=bartv@ecoscentric.com \
--cc=ecos-devel@sourceware.org \
--cc=uwe.kindler@cetoni.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).