Hi Patrick,
On 9 Feb 2012, at 05:10, Patrick Marlier wrote:
On 02/08/2012 12:12 AM, Jack Howarth wrote:
I believe the remaining libitm.c++/eh-1.C execution test failures
are due to
the weakref linker bug currently in Xcode 4.x (radr://10466868)
which I hae been
told will be fixed in the next Xcode release after Xcode 4.3.
Jack
Humm... In fact, not completely. Of course, if the linker was
working, the HAVE_ELF_STYLE_WEAKREF will be defined and no problem.
Otherwise in the eh-1.c, we can see that
_ITM_cxa_allocation_exception is using the dummy function
__cxa_allocation_exception defined into eh_cpp.cc but not the one
from libstdc++. There is no dynamic symbol resolution since the
function is defined in the file.
I do not really know why those functions are defined here, I think
it may causes more problems than it solves for darwin.
When Rainer introduced this, he mentioned "on Tru64 UNIX. Of course
it cannot work to provide only a single dummy function, but all weak
definitions must be backed by dummy definitions on that platform."
http://patchwork.ozlabs.org/patch/126007/
Iain mentioned this when he introduced the dummy def for darwin:
*** FWIW, weakref actually work (at runtime) for earlier Darwin
Weak refs have been working a (long) time on Darwin @ runtime - don't
remember what version they were introduced ... but maybe from almost/
actually the start.
- it's just that refs either need to be satisfied by dummies at link
time -
We are dealing with tool bugs (or, at least, changes in behavior) -
the Linker would not [intentionally, see below*] accept unsatisfied
linkage for weak refs @ Darwin <= 9 (XCode 3.1.4) ... and then for
the XCode 3.2.x tool-chain on Darwin 10 it does accept it (i.e. ELF-
like semantics work). Then (an acknowledged bug) with the (current)
XCode 4.x tool-chain on either D10 or D11 the linker is again not
accepting.
* The (original, Darwin version, weak ref) idea, as documented, is
that weak refs are for optional features - so the developer @ link-
time supplies the library reference (place where the reference would
be found, if present - this tells dyld what the proper two-level name
of the lib is, when present). Then, at runtime dyld should not barf
if the reference is not present. This is a different approach from
the ELF weak-ref where the reference does not need to be supplied @
link-time - although it seems that Darwin is shifting towards
supporting both from D10 onwards.
- or the library namespace has to be flattened (which is generally
undesirable).
this would be a (IMO very) Bad Idea because we'd be doing it for every
exe that included libitm... bleah. The two-level lib namespace is one
of Darwin's nicer features ;)
I think refs (from libstdc++) should be satisfied at link time with -
lstdc++ but probably I am missing something?
when you link c++ code, that is what is required .. but obv. we don't
want lstdc++ on the link line for c (because the library *will* be
found @ runtime - and thus the routines would be called).
I have an idea ... perhaps we supply (yet another) crt that is linked
last on the line and provides the dummies. That way the linkage will
be satisfied from libstd++ for c++ and the dummies for c.
will try and see if I can fit a trial of that idea in on D9 & D10.
Note that removing definitions in eh_cpp.cc make the test passes.
but it will make the c tests fail for D9 and any version of Darwin on
which elf-style weak refs is not currently working ...
cheers
Iain
Thanks guys!
--
Patrick.
