[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #50 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-11 17:54:44 UTC --- (In reply to comment #47) Created attachment 29396 [details] revised patch to revert r184293 while fixing PR55693 Bootstrap regtesting underway on ppc darwin9, x86_64 darwin10 with Xcode 4.2 and x86_64 darwin12 with Xcode 4.6. Iain confirmed off-list that the proposed patch to remove the dummy function bootstraps on i686 drawin9 without regressions in the tm and libitm testsuite.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #51 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2013-02-11 23:30:18 UTC --- Author: mrs Date: Mon Feb 11 23:30:10 2013 New Revision: 195960 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195960 Log: /libgcc 2013-02-11 Iain Sandoe i...@codesourcery.com Jack Howarth howa...@bromo.med.uc.edu Patrick Marlier patrick.marl...@gmail.com PR libitm/55693 * config/darwin-crt-tm.c: Remove dummy functions hack. /gcc 2013-02-11 Iain Sandoe i...@codesourcery.com Jack Howarth howa...@bromo.med.uc.edu Patrick Marlier patrick.marl...@gmail.com PR libitm/55693 * config/darwin.h: Replace ENDFILE_SPEC with TM_DESTRUCTOR and define ENDFILE_SPEC as TM_DESTRUCTOR. * config/i386/darwin.h (ENDFILE_SPEC): Use TM_DESTRUCTOR. /libitm 2013-02-11 Iain Sandoe i...@codesourcery.com Jack Howarth howa...@bromo.med.uc.edu Patrick Marlier patrick.marl...@gmail.com PR libitm/55693 * alloc_cpp.cc: Enable function declarations on darwin. * eh_cpp.cc: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.h trunk/gcc/config/i386/darwin.h trunk/libgcc/ChangeLog trunk/libgcc/config/darwin-crt-tm.c trunk/libitm/ChangeLog trunk/libitm/alloc_cpp.cc trunk/libitm/eh_cpp.cc
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 m...@gcc.gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.8.0 Resolution||FIXED --- Comment #52 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2013-02-11 23:36:32 UTC --- Fixed.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #46 from Patrick Marlier patrick.marlier at gmail dot com 2013-02-08 11:46:33 UTC --- Jack, I am sorry to be picky but are dummy functions still required in libgcc/config/darwin-crt-tm.c? I haven't access to a machine with __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ 1060 to check that. In case I am completely wrong, just ignore this message. Thanks. -- Patrick
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #47 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-08 14:39:11 UTC --- Created attachment 29396 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29396 revised patch to revert r184293 while fixing PR55693 Bootstrap regtesting underway on ppc darwin9, x86_64 darwin10 with Xcode 4.2 and x86_64 darwin12 with Xcode 4.6.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #48 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-08 14:40:20 UTC --- (In reply to comment #47) Created attachment 29396 [details] revised patch to revert r184293 while fixing PR55693 Bootstrap regtesting underway on ppc darwin9, x86_64 darwin10 with Xcode 4.2 and x86_64 darwin12 with Xcode 4.6. Reverting the dummy function addition to libgcc/config/darwin-crt-tm.c to be precise.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #49 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-08
18:17:50 UTC ---
The patch in comment 47 produces no regressions in gcc for...
make -k check RUNTESTFLAGS=tm.exp --target_board=unix'{-m32,-m64}'
and none in libitm for...
make -k check RUNTESTFLAGS=--target_board=unix'{-m32,-m64}'
on powerpc-apple-darwin9 with Xcode 3.1.4, x86_64-apple-darwin10 with Xcode 4.2
and x86_64-apple-darwin12 with Xcode 4.6. So it seems we may not need the dummy
functions at all.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #44 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-07 19:33:24 UTC --- Created attachment 29389 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29389 revised patch to fix darwin10 under Xcode 4.2 The attached patch removes the !defined (__MACH__) hacks from libitm/alloc_cpp.cc and libitm/eh_cpp.cc so that the symbols for _ZdlPv*, etc can be found on darwin10 with Xcode 4.2 (which doesn't set HAVE_ELF_STYLE_WEAKREF in configure but also doesn't define the weak dummy functions because of fast c++ weak-symbol coalescing). Bootstrap regression tested for tm.exp and libitm subdirectory on x86_64-apple-darwin10 with Xcode 4.2 and x86_64-apple-darwin12 with Xcode 4.6. Can someone test darwin9 and x86_64-apple-darwin10 with Xcode 3.2.6 to make sure that the linker bug mentioned in the previous patch (http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00851.html) doesn't re-appear?
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #45 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-02-07 21:59:38 UTC --- ... Bootstrap regression tested for tm.exp and libitm subdirectory on x86_64-apple-darwin10 with Xcode 4.2 and x86_64-apple-darwin12 with Xcode 4.6. Can someone test darwin9 and x86_64-apple-darwin10 with Xcode 3.2.6 to make sure that the linker bug mentioned in the previous patch (http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00851.html) doesn't re-appear? With the new patch, the same tests (tm.exp and libitm) passed without regression on x86_64-apple-darwin10 with Xcode 3.2.6. If needed I can repeat it for ppc-d9, but don't expect any result before the end of the week-end.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 m...@gcc.gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added CC||mrs at gcc dot gnu.org --- Comment #43 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2013-02-04 19:51:13 UTC --- So, I think we're at the point where the patch from #37 is the right way forward. If people agree, I'll approve that.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #42 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-25 13:23:12 UTC --- Full regression testing on x86_64-apple-darwin12 of proposed patch to supply dummy functions as a static archive shows no regressions in any tm tests... http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg02648.html
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #39 from Iain Sandoe iains at gcc dot gnu.org 2013-01-24 11:34:20 UTC --- (In reply to comment #38) Tested proposed patch from Comment 37 on x86_64-apple-darwin11 and x86_64-apple-darwin12 with Xcode 4.5.2 on both systems. No regressions are found in darwin_objdir/x86_64-apple-darwin11.4.2/libitm build directory. Looks good to go. FAOD, I was not (at this stage) proposing comment #37 as a fix - but rather to demonstrate what seems to be inconsistent behavior in the linker. The inconsistency is: (where there is a reference made in other objects to some symbol(s) present in both the dylib and the object): other objects and libs dlib with non-weak symbols object with weak symbols causes the references to be satisfied from the object, NOT the dylib. (and also seems unexpected to me) whereas: other objects and libs dylib with non-weak symbols static archive containing one object with weak symbols causes the symbols to be resolved from the dylib (which is what I would have expected) === IFF that behavior is as expected and documented - then, fine - the patch is a fix, but I think we need to establish what is expected behavior - or we will be going around this loop again in 6 months, 1 year .. etc.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #40 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-24 14:54:34 UTC --- (In reply to comment #39) My understanding from Nick's comments was that the ld64/dyld behavior is now as follows. For performance reasons, weak coalescing is only done if the weak symbols occur in a library (shared or static) and those symbols that are marked weak in object files are not weak coalesced by dyld. His comments weren't explicit on that point and I've asked him to confirm that your work-around of using a static library for the weak symbols isn't exploiting a 'bug' in ld64/dyld that will disappear in a future Xcode release. I should also note that your patch does produce some regressions on darwin10 with Xcode 4.2 but this shouldn't shock anyone as we are well aware that -undefined dynamic_lookup was broken from Xcode 4.2 until it was fixed again in Xcode 4.4 (radr://10466868). I wouldn't worry about this as... 1) The Xcode 4.x series was never fully supported on darwin10 and only briefly made available to end-users. Users on darwin10 really need to stick to Xcode 3.2.6 to avoid the -undefined dynamic_lookup bug introduced at Xcode 4.2. 2) Users on darwin11/12 can use any Xcode after 4.4 which are all freely available from Apple on connect.apple.com. There is a limit to the number of linker bugs that can be worked around at the same time in FSF gcc on darwin and I would focus more on those Xcode releases which provided expected behavior rather than buggy behavior. IMHO, the current situation is unacceptable for libitm and needs to be fixed since for all modern (supported) darwin (10/11/12), the stub symbols in crttme.o are overriding those in libstdc++. ps On darwin10 with Xcode 4.2, the failures are all of the form... dyld: Symbol not found: __ZdaPv Referenced from: /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libitm/.libs/libitm.1.dylib Expected in: flat namespace in /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libitm/.libs/libitm.1.dylib FAIL: libitm.c/cancel.c execution test
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #41 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-24 15:23:54 UTC --- Iain, I believe the current behavior of dyld in darwin10/11/12 is clearly described in... http://developer.apple.com/library/mac/#releasenotes/DeveloperTools/RN-dyld/_index.html Specifically in the section... Faster Weak-symbol Coalescing C++ uses weak definitions to solve a number of issues. But if weak symbols are not hidden, the dynamic loader needs to make them unique at runtime. The previous algorithm for doing that was expensive. For every weak symbol in each image, the dynamic loader would look up that symbol in every other image. In OS X v10.6 the algorithm is more efficient: It assumes that weak-symbol duplicates are rare. First, all symbols are bound by their normal two-level namespace binding. Then there is as a separate pass that takes an alphabetized list of weak symbols from each image and iterates through just those weak symbols looking for duplicates. The dynamic loader updates only the duplicates. The new LINKEDIT segment format is optimized for this algorithm. This issue seems to also be described in this thread on cfe-commits... http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120625/059752.html http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120625/059755.html http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120625/059793.html http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120625/059796.html http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120625/059799.html http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120625/059803.html http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120625/059807.html http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120625/059819.html http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120625/059825.html
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #21 from Iain Sandoe iains at gcc dot gnu.org 2013-01-23 08:44:45
UTC ---
(In reply to comment #20)
crttme.o comes from libgcc/config/darwin-crt-tm.c, which has:
/* Provide dummy functions to satisfy linkage for versions of the Darwin
tool-chain that that can't handle undefined weak refs at the link stage.
??? Define these dummy functions only when !HAVE_ELF_STYLE_WEAKREF. */
extern void *__cxa_allocate_exception (size_t) WEAK;
...
...
void *__cxa_allocate_exception (size_t s UNUSED) { return NULL; }
This looks like the NULL returning __cxa_allocate_exception that is causing
all
this grief, and came from Patrick Marlier and Iain Sandoe's patch here:
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00851.html
Again, I'm a Darwin wimp. Anyone care to comment?
looks like (yet another) permutation of what works/doesn't with ELF-style weak
linking I don't have darwin11 or 12 (yet) - but should do soon.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23 09:43:31 UTC --- Would it help if libitm has been linked against libstdc++ on the targets which can't support weak properly?
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #23 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-23 09:56:13 UTC --- (In reply to comment #21) ... I don't have darwin11 or 12 (yet) - but should do soon. The test also fails on darwin10 unless the patch in comment #7 is applied.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #24 from Iain Sandoe iains at gcc dot gnu.org 2013-01-23 13:33:15 UTC --- (In reply to comment #23) (In reply to comment #21) ... I don't have darwin11 or 12 (yet) - but should do soon. The test also fails on darwin10 unless the patch in comment #7 is applied. indeed it does (with xcode 3.2.6) and passes on x86-Darwin9 OK - so a recap; weak linking works just fine on Darwin - with the semantics that Darwin defines (where references are provided at link time, but may be missing at run time). Some versions of Darwin's tool chain components and dynamic linker also support ELF-style weak linking semantics. However, in this case, the references *are* present on the link line (lstdc++) but also a duplicate in crttme.o --- So, in this case (at least on x86-darwin10), I am not yet sure exactly where the problem lies. since -lstdc++ is on the link line (ahead of crttme.o) - I would expect darwin to resolve the __cxa__ symbols from the shared library. It is not doing so - and I (or someone) need(s) to re-check the priority of satisfying linkage. It might be that naming the crt as a .o forces it to be processed ahead of the shared lib. In which case, perhaps we can modify our crttme to be an arch containing that single object. [on Darwin10] If I manually remove the crttme.o from the link line, the testcase executes OK. Time is v. short at the moment - prob won't have a chance to investigate further for a couple of weeks.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #25 from Aldy Hernandez aldyh at redhat dot com 2013-01-23 14:11:53 UTC --- looks like (yet another) permutation of what works/doesn't with ELF-style weak linking I don't have darwin11 or 12 (yet) - but should do soon. FWIW, I reproduced the problem on Darwin10 (x86_64-apple-darwin10.8.0). Mac OS X 10.6.8.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #26 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-23 16:44:51 UTC --- Iain, The initial comments from the darwin linker developer were... That test case is dying because a.out contains its own copy of __cxa_allocate_exception which just returns NULL. How was a.out built? It looks like it linked with some bogus static copy of the libc++ runtime. Are you expecting that because these bogus cxa functions are weak, they will be overridden at runtime by the real version? Weak linking does not work quite that way on darwin. For performance, the only symbols which dyld checks for weak coalescing are those which the static linker marked as needing weak binding. You can see those with dyldinfo -weak_bind. In a.out __cxa_allocate_exception is marked for weak binding check, but in libc++abi.dylib does not mark those as weak, so dyld is not coalescing those symbols and the a.out wind up running with its own bogus implementation. Can you just not link a.out with the bogus implementation?
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #27 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-23 16:48:19 UTC --- (In reply to comment #25) FWIW, I reproduced the problem on Darwin10 (x86_64-apple-darwin10.8.0). Mac OS X 10.6.8. What Xcode do you have installed? Is it 3.2.6 or one of the 4.x series? The linker got a major rewrite in 4.0.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #28 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-23 17:32:34 UTC --- Iain, The ELF style weak ref issue appears to be red herring. I find that both darwin10 with Xcode 4.2 (whose build of libitm has a config.h with HAVE_ELF_STYLE_WEAKREF undefined) and darwin11/12 with Xcode 4.5.2 (which results in config.h having HAVE_ELF_STYLE_WEAKREF defined) exhibit this regression. In both cases, removing the trailing linkage on -lcrttme.o eliminates the segfaults in the test case. Is there some way to modify darwin.h's SPEC handling so that the linkage on -lcrttme.o isn't passed for the g++ compiler? As I understand this, we are only linking in crttme.o to provide stub symbols when libstdc++ linkage isn't present to provide those symbols.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #29 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-23 18:30:37 UTC --- (In reply to comment #27) FWIW, I reproduced the problem on Darwin10 (x86_64-apple-darwin10.8.0). Mac OS X 10.6.8. What Xcode do you have installed? Is it 3.2.6 or one of the 4.x series? The linker got a major rewrite in 4.0. The test fails also with Xcode 3.2.6.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #30 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-23 19:32:22 UTC --- Created attachment 29256 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29256 test case demonstrating need for weak symbols in crttme.o
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #31 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-23
19:41:52 UTC ---
I believe the attached testcase, weak_symbol.tar.bz2, demonstrates that the
solution on darwin is to mark the duplicate symbols in crttme.o as weak.
Consider the following test case...
% cat fun.c
extern void foo(void) __attribute__((weak));
void fun(void)
{
if (foo) foo();
}
% cat foo.c
#include stdio.h
void foo(void)
{
printf(Hello!\n);
}
% cat bar.c
#include stdio.h
void foo(void) __attribute__((weak));
void foo(void)
{
printf(Goodbye!\n);
}
% cat weak_test.c
#include stdio.h
void fun(void);
int main()
{
fun();
return 0;
}
compiled as...
clang -c fun.c
clang -dyanmiclib -shared -Wl,-undefined -Wl,dynamic_lookup -o libfun.dylib
fun.o
clang -c foo.c
clang -dyanmiclib -shared -Wl,-undefined -Wl,dynamic_lookup -o libfoo.dylib
foo.o
clang -c bar.c
clang -c weak_test.c
clang -o weak_test weak_test.o ./libfoo.dylib ./libfun.dylib bar.o
clang -o weak_test2 weak_test.o ./libfun.dylib bar.o
This gives...
setenv DYLD_LIBRARY_PATH .
% ./weak_test
Hello!
% ./weak_test2
Goodbye!
which argues that if we mark the weak symbols from eh_cpp.cc as weak in
crttme.o as well, those symbols can be overridden by the ones in libstdc++ as
expected. Also, this eliminates the need to place libstdc++ first...
% clang -o weak_test3 weak_test.o ./libfun.dylib bar.o ./libfoo.dylib
% ./weak_test3
Hello!
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #32 from Iain Sandoe iains at gcc dot gnu.org 2013-01-23 19:59:40 UTC --- (In reply to comment #31) solution on darwin is to mark the duplicate symbols in crttme.o as weak. seems reasonable - can you try that?
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #33 from Iain Sandoe iains at gcc dot gnu.org 2013-01-23 20:14:26
UTC ---
(In reply to comment #32)
(In reply to comment #31)
solution on darwin is to mark the duplicate symbols in crttme.o as weak.
seems reasonable - can you try that?
... except that all those symbols should already be weak:
/* Provide dummy functions to satisfy linkage for versions of the Darwin
tool-chain that that can't handle undefined weak refs at the link stage.
??? Define these dummy functions only when !HAVE_ELF_STYLE_WEAKREF. */
extern void *__cxa_allocate_exception (size_t) WEAK;
extern void __cxa_throw (void *, void *, void *) WEAK;
extern void *__cxa_begin_catch (void *) WEAK;
extern void *__cxa_end_catch (void) WEAK;
extern void __cxa_tm_cleanup (void *, void *, unsigned int) WEAK;
extern void *_ZnwX (size_t) WEAK;
extern void _ZdlPv (void *) WEAK;
extern void *_ZnaX (size_t) WEAK;
extern void _ZdaPv (void *) WEAK;
typedef const struct nothrow_t { } *c_nothrow_p;
extern void *_ZnwXRKSt9nothrow_t (size_t, c_nothrow_p) WEAK;
extern void _ZdlPvRKSt9nothrow_t (void *, c_nothrow_p) WEAK;
extern void *_ZnaXRKSt9nothrow_t (size_t, c_nothrow_p) WEAK;
extern void _ZdaPvRKSt9nothrow_t (void *, c_nothrow_p) WEAK;
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #34 from Iain Sandoe iains at gcc dot gnu.org 2013-01-23 20:35:47 UTC --- (In reply to comment #24) However, in this case, the references *are* present on the link line (lstdc++) but also a duplicate in crttme.o since -lstdc++ is on the link line (ahead of crttme.o) - I would expect darwin to resolve the __cxa__ symbols from the shared library. It is not doing so - and I (or someone) need(s) to re-check the priority of satisfying linkage. $ nm -mapv /usr/lib/libstdc++.6.dylib |grep __cxa_allo 000452e8 (__TEXT,__text) external ___cxa_allocate_exception $ nm -mapv /GCC/gcc-live-trunk-build/i686-apple-darwin9/libgcc/crttme.o |grep __cxa_allo 0100 (__TEXT,__textcoal_nt) weak external ___cxa_allocate_exception In fact, since the libstdc++ symbols is NOT weak, and the crttme.o is ... ... ISTR non-weak should override weak - but need to re-RTFM. if that is the case, one is tempted to speculate that this might be a ld64 bug. It might be that naming the crt as a .o forces it to be processed ahead of the shared lib. In which case, perhaps we can modify our crttme to be an arch containing that single object. I have a work-around hack in test.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #35 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-23 21:13:16 UTC --- What's up with the comment /* Provide dummy functions to satisfy linkage for versions of the Darwin tool-chain that that can't handle undefined weak refs at the link stage. ??? Define these dummy functions only when !HAVE_ELF_STYLE_WEAKREF. */ in libgcc/config/darwin-crt-tm.c? In particular, what versions of the Darwin tool chain were you using that required these dummy functions?
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #36 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-23 21:27:41 UTC --- The darwin linker developers comments on the testcase I uploaded were... The term weak is way overloaded. The original bug was about weak definitions which is how C++ coalescing is done. Your example uses weak imports which means the symbol can be missing at runtime (because the runtime version of the dylib is different than the build time). You(r) example also uses -dynamic_lookup which tells dyld to look everywhere for a symbol (normally it only looks in one dylib at runtime). Iain, reread Comment 26. He seems to be saying that having weak symbols in object files is insufficient to override those in shared libraries. I guess the offending object file would have to be made into a shared library for the weak symbols to be honored as weak by the linker.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #37 from Iain Sandoe iains at gcc dot gnu.org 2013-01-23 22:16:10 UTC --- Created attachment 29262 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29262 test, supply the dummy functions from a static archive. in the current code, the following sequence: -lstdc++ -lcrttme.o results in the functions from crttme.o being linked in preference (regardless that they are marked weak and the ones in libstdc++.6.dylib are not). the patch places the crttme.o into a static archive [libcrttme.a] -lstdc++ -lcrttme now the functions are linked from libstdc++.6.dylib (as I would have expected). At this stage, this is just a piece of code to illustrate a point. it functions on darwin10 with 3.2.6 (and the patch does not change the behavior on darwin9 which was already working) = from the reports in preceding comments, I think that the dialogues with the vendor's developers have become confused - we need to (a) re-read the doc. (b) restate the problem succinctly. Does this code function on Darwin 11/12?
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #38 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-24
05:54:24 UTC ---
Tested proposed patch from Comment 37 on x86_64-apple-darwin11 and
x86_64-apple-darwin12 with Xcode 4.5.2 on both systems. No regressions are
found with either
make -k check RUNTESTFLAGS=tm.exp --target_board=unix'{-m32,-m64}'
in darwin_objdir/gcc build directory or with
make -k check RUNTESTFLAGS=--target_board=unix'{-m32,-m64}'
in darwin_objdir/x86_64-apple-darwin11.4.2/libitm build directory. Looks good
to go.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #19 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-23
04:01:17 UTC ---
(In reply to comment #12)
BTW, the reason this works when forcing the instrumented path as Torvald
suggested (comment #7) is because when f1() is instrumented, the call to
__cxa_allocate_exception is also instrumented and we actually call:
dyld_stub__ITM_cxa_allocate_exception() - _ITM_cxa_allocate_exception, which
is defined in libitm/eh_cpp.cc:
void *
_ITM_cxa_allocate_exception (size_t size)
{
void *r = __cxa_allocate_exception (size);
gtm_thr()-cxa_unthrown = r;
return r;
}
Assembly single stepping through the above shows that the call to
__cxa_allocate_exception (through dyld_stub___cxa_allocate_exception) has a
correct stub, not this return 0 nonsense I describe in comment #10.
I appears that the undesired __cxa_allocate_exception) symbol defined in the
resulting a.out is coming from the -lcrttme.o linkage added by the spec for
-fgnu-tm on darwin. I drop -lcrttme.o from the linkage...
/usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.8.2
-weak_reference_mismatches non-weak -o a.out -lcrttms.o
-L/sw/lib/gcc4.8/lib/gcc/x86_64-apple-darwin12.2.0/4.8.0
-L/sw/lib/gcc4.8/lib/gcc/x86_64-apple-darwin12.2.0/4.8.0/../../.. a.o -lstdc++
-litm -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -lcrttme.o -v
the testcase runs fine.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
Aldy Hernandez aldyh at gcc dot gnu.org changed:
What|Removed |Added
CC||patrick.marlier at gmail
||dot com
--- Comment #20 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-01-23
04:34:26 UTC ---
crttme.o comes from libgcc/config/darwin-crt-tm.c, which has:
/* Provide dummy functions to satisfy linkage for versions of the Darwin
tool-chain that that can't handle undefined weak refs at the link stage.
??? Define these dummy functions only when !HAVE_ELF_STYLE_WEAKREF. */
extern void *__cxa_allocate_exception (size_t) WEAK;
...
...
void *__cxa_allocate_exception (size_t s UNUSED) { return NULL; }
This looks like the NULL returning __cxa_allocate_exception that is causing all
this grief, and came from Patrick Marlier and Iain Sandoe's patch here:
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00851.html
Again, I'm a Darwin wimp. Anyone care to comment?
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #18 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-19 17:11:23 UTC --- Opened radar://13048248 in case these failing test cases represent an unwinder bug on darwin.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #14 from Aldy Hernandez aldyh at redhat dot com 2013-01-18 17:14:56 UTC --- You can use DYLD_PRINT_BINDINGS to find out which __cxa_allocate_exception call is being used, it'll also give you the addresses so you can make sure that the right one is being called as you step through. DYLD_PRINT_BINDINGS doesn't even list __cxa_allocate_exception for a simple program with a throw. dyld: bind: libgcc_s.1.dylib:0x100998000 = libSystem.B.dylib:dyld_stub_binder, *0x100998000 = 0x7FFF80F46F94 dyld: bind: libstdc++.6.dylib:0x1000AD0A0 = libSystem.B.dylib:__DefaultRuneLocale, *0x1000AD0A0 = 0x7FFF701FFBE0 dyld: bind: libstdc++.6.dylib:0x1000AD1C8 = libSystem.B.dylib:___mb_cur_max, *0x1000AD1C8 = 0x7FFF70200898 dyld: bind: libstdc++.6.dylib:0x1000AD020 = libSystem.B.dylib:___stderrp, *0x1000AD020 = 0x7FFF701FD2F8 dyld: bind: libstdc++.6.dylib:0x1000AD0B8 = libSystem.B.dylib:___stdinp, *0x1000AD0B8 = 0x7FFF701FD2E8 dyld: bind: libstdc++.6.dylib:0x1000AD0A8 = libSystem.B.dylib:___stdoutp, *0x1000AD0A8 = 0x7FFF701FD2F0 dyld: bind: libstdc++.6.dylib:0x1000AD000 = libSystem.B.dylib:dyld_stub_binder, *0x1000AD000 = 0x7FFF80F46F94 dyld: bind: libitm.1.dylib:0x100157020 = eh-1.exe:__ZdaPv, *0x100157020 = 0x10960 dyld: bind: libitm.1.dylib:0x100157018 = eh-1.exe:__ZdlPv, *0x100157018 = 0x10940 dyld: bind: libitm.1.dylib:0x100157028 = libSystem.B.dylib:__DefaultRuneLocale, *0x100157028 = 0x7FFF701FFBE0 dyld: bind: libitm.1.dylib:0x100157030 = libSystem.B.dylib:___stderrp, *0x100157030 = 0x7FFF701FD2F8 dyld: bind: libitm.1.dylib:0x100157010 = libSystem.B.dylib:_free, *0x100157010 = 0x7FFF80E45115 dyld: bind: libitm.1.dylib:0x100157000 = libSystem.B.dylib:dyld_stub_binder, *0x100157000 = 0x7FFF80F46F94 dyld: bind: eh-1.exe:0x11010 = libstdc++.6.dylib:__ZTIi, *0x11010 = 0x1000AE2C0 dyld: bind: eh-1.exe:0x11028 = libstdc++.6.dylib:___gxx_personality_v0, *0x11028 = 0x159D0 dyld: bind: eh-1.exe:0x11020 = libitm.1.dylib:__ITM_deregisterTMCloneTable, *0x11020 = 0x10013FED7 dyld: bind: eh-1.exe:0x11018 = libitm.1.dylib:__ITM_registerTMCloneTable, *0x11018 = 0x10013FE45 dyld: bind: eh-1.exe:0x11000 = libSystem.B.dylib:dyld_stub_binder, *0x11000 = 0x7FFF80F46F94 dyld: weak bind: libstdc++.6.dylib:0x1000AD010 = eh-1.exe:__ZdaPv, *0x1000AD010 = 0x10960 dyld: weak bind: libstdc++.6.dylib:0x1000AD458 = eh-1.exe:__ZdaPv, *0x1000AD458 = 0x10960 dyld: weak bind: libstdc++.6.dylib:0x1000AD460 = eh-1.exe:__ZdlPv, *0x1000AD460 = 0x10940 dyld: lazy bind: libstdc++.6.dylib:0x1000AD600 = libSystem.B.dylib:_pthread_key_create, *0x1000AD600 = 0x7FFF80E4221A dyld: lazy bind: libstdc++.6.dylib:0x1000AD488 = libSystem.B.dylib:___cxa_atexit, *0x1000AD488 = 0x7FFF80E44981 dyld: lazy bind: libitm.1.dylib:0x1001570F0 = libSystem.B.dylib:___cxa_atexit, *0x1001570F0 = 0x7FFF80E44981 dyld: lazy bind: eh-1.exe:0x11080 = libSystem.B.dylib:_dladdr, *0x11080 = 0x7FFF80E44D9A dyld: lazy bind: eh-1.exe:0x11090 = libSystem.B.dylib:_getsectdatafromheader_64, *0x11090 = 0x7FFF80E44BA6
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added AssignedTo|aldyh at gcc dot gnu.org|unassigned at gcc dot ||gnu.org --- Comment #15 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-01-18 17:22:56 UTC --- Ok, I'm going to put this PR back in the queue for someone else to look at. I have debugged enough for a Darwin savvy person to attack, but my lack of Darwin shlib foo is hindering progress here. FWIW, DYLD_PRINT_LIBRARIES below shows that we are loading the built libstdc++ and libitm shared libraries. I am more than happy to try more options as I already have a build set up. And for the record, below is an easy way to reproduce the problem with libitm/testsuite/libitm.c++/eh-1.C: Yanory-Hernandezs-MacBook:testsuite aldyh$ sh y + SRC=/mnt/gcc/libitm/testsuite/libitm.c++/eh-1.C + /Users/aldyh/bld/1/gcc/xgcc -B/Users/aldyh/bld/1/gcc/ /mnt/gcc/libitm/testsuite/libitm.c++/eh-1.C -B/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/./libitm/ -I/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/./libitm -I/mnt/gcc/libitm/testsuite/.. -shared-libgcc -fmessage-length=0 -fgnu-tm -nostdinc++ -I/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/libstdc++-v3/include/x86_64-apple-darwin10.8.0 -I/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/libstdc++-v3/include -I/mnt/gcc/libstdc++-v3/libsupc++ -I/mnt/gcc/libstdc++-v3/include/backward -I/mnt/gcc/libstdc++-v3/testsuite/util -L/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/./libitm/.libs -L/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/./libitm/../libstdc++-v3/src/.libs -shared-libgcc -lstdc++ -lm -g -o ./eh-1.exe + export DYLD_LIBRARY_PATH=.:/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/./libitm/.libs:/Users/aldyh/bld/1/gcc:/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/./libitm/../libstdc++-v3/src/.libs:.:/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/./libitm/.libs:/Users/aldyh/bld/1/gcc:/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/./libitm/../libstdc++-v3/src/.libs + DYLD_LIBRARY_PATH=.:/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/./libitm/.libs:/Users/aldyh/bld/1/gcc:/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/./libitm/../libstdc++-v3/src/.libs:.:/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/./libitm/.libs:/Users/aldyh/bld/1/gcc:/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/./libitm/../libstdc++-v3/src/.libs + export DYLD_PRINT_LIBRARIES=1 + DYLD_PRINT_LIBRARIES=1 + ./eh-1.exe dyld: loaded: /Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/libitm/testsuite/./eh-1.exe dyld: loaded: /Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/./libitm/../libstdc++-v3/src/.libs/libstdc++.6.dylib dyld: loaded: /Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/./libitm/.libs/libitm.1.dylib dyld: loaded: /usr/lib/libSystem.B.dylib dyld: loaded: /Users/aldyh/bld/1/gcc/libgcc_s.1.dylib dyld: loaded: /usr/lib/system/libmathCommon.A.dylib y: line 11: 89286 Segmentation fault ./eh-1.exe
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #16 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-18 22:02:08 UTC --- If I compile the failing test case from comment 10 with... % g++-fsf-4.8 -static-libgcc -fgnu-tm a.C % otool -L ./a.out ./a.out: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) the test case no longer segfaults but aborts... % ./a.out Abort Also this test case behaves the same in FSF gcc 4.6.3 and 4.7.2. The shared linkage to libstdc++ and libitm segfaults and the static linkage aborts. Note that a statically link in libgcc, libstdc++ and libitm under linux, the test case runs without error.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #17 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-18
22:15:37 UTC ---
A walk from f1 in the statically linked a.C testcase looks like...
(gdb) b f1
Breakpoint 1 at 0x11764: file a.C, line 2.
(gdb) disp/i $pc
(gdb) r
Starting program: /Users/howarth/new_eh_bug/a.out
Reading symbols for shared libraries +. done
Breakpoint 1, 0x00011764 in f1 () at a.C:2
2throw 1;
1: x/i $pc 0x11764 f1+4:mov$0x4,%edi
(gdb) si
0x000117692throw 1;
1: x/i $pc 0x11769 f1+9:callq 0x1a680
__cxa_allocate_exception
(gdb)
__cxa_allocate_exception (thrown_size=4) at
../../../../gcc-4.8-20130118/libstdc++-v3/libsupc++/eh_alloc.cc:102
102{
1: x/i $pc 0x1a680 __cxa_allocate_exception:push %rbp
(gdb)
105 thrown_size += sizeof (__cxa_refcounted_exception);
1: x/i $pc 0x1a681 __cxa_allocate_exception+1:lea0x80(%rdi),%rbp
(gdb)
102{
1: x/i $pc 0x1a688 __cxa_allocate_exception+8:push %rbx
(gdb)
106 ret = malloc (thrown_size);
1: x/i $pc 0x1a689 __cxa_allocate_exception+9:mov%rbp,%rdi
(gdb)
102{
1: x/i $pc 0x1a68c __cxa_allocate_exception+12:sub$0x8,%rsp
(gdb)
106 ret = malloc (thrown_size);
1: x/i $pc 0x1a690 __cxa_allocate_exception+16:callq 0x10001f960
dyld_stub_malloc
(gdb)
0x00010001f960 in dyld_stub_malloc ()
1: x/i $pc 0x10001f960 dyld_stub_malloc:jmpq *0xc7aa(%rip)#
0x10002c110
(gdb)
0x00010001fad0 in dyld_stub___cxa_tm_cleanup ()
1: x/i $pc 0x10001fad0:pushq $0x1d3
(gdb)
0x00010001fad5 in dyld_stub___cxa_tm_cleanup ()
1: x/i $pc 0x10001fad5:jmpq 0x10001f9f8
(gdb)
0x00010001f9f8 in dyld_stub___cxa_tm_cleanup ()
1: x/i $pc 0x10001f9f8:lea0xc661(%rip),%r11# 0x10002c060
(gdb)
0x00010001f9ff in dyld_stub___cxa_tm_cleanup ()
1: x/i $pc 0x10001f9ff:push %r11
(gdb)
0x00010001fa01 in dyld_stub___cxa_tm_cleanup ()
1: x/i $pc 0x10001fa01:jmpq *0xc651(%rip)# 0x10002c058
(gdb)
0x7fff847c9878 in dyld_stub_binder ()
1: x/i $pc 0x7fff847c9878 dyld_stub_binder:push %rbp
(gdb)
0x7fff847c9879 in dyld_stub_binder ()
1: x/i $pc 0x7fff847c9879 dyld_stub_binder+1:mov%rsp,%rbp
(gdb)
0x7fff847c987c in dyld_stub_binder ()
1: x/i $pc 0x7fff847c987c dyld_stub_binder+4:sub$0xc0,%rsp
(gdb)
0x7fff847c9883 in dyld_stub_binder ()
1: x/i $pc 0x7fff847c9883 dyld_stub_binder+11:mov%rdi,(%rsp)
(gdb)
0x7fff847c9887 in dyld_stub_binder ()
1: x/i $pc 0x7fff847c9887 dyld_stub_binder+15:mov%rsi,0x8(%rsp)
(gdb)
0x7fff847c988c in dyld_stub_binder ()
1: x/i $pc 0x7fff847c988c dyld_stub_binder+20:mov%rdx,0x10(%rsp)
(gdb)
0x7fff847c9891 in dyld_stub_binder ()
1: x/i $pc 0x7fff847c9891 dyld_stub_binder+25:mov%rcx,0x18(%rsp)
(gdb)
0x7fff847c9896 in dyld_stub_binder ()
1: x/i $pc 0x7fff847c9896 dyld_stub_binder+30:mov%r8,0x20(%rsp)
(gdb)
0x7fff847c989b in dyld_stub_binder ()
1: x/i $pc 0x7fff847c989b dyld_stub_binder+35:mov%r9,0x28(%rsp)
(gdb)
0x7fff847c98a0 in dyld_stub_binder ()
1: x/i $pc 0x7fff847c98a0 dyld_stub_binder+40:mov%rax,0x30(%rsp)
(gdb)
0x7fff847c98a5 in misaligned_stack_error_entering_dyld_stub_binder ()
1: x/i $pc 0x7fff847c98a5 misaligned_stack_error_entering_dyld_stub_binder:
movdqa %xmm0,0x40(%rsp)
The testcase passes at -m32 which makes me wonder if libitm is honoring
darwin's requirements of a 128 stackboundary at -m64.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
Aldy Hernandez aldyh at gcc dot gnu.org changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org
|gnu.org |
--- Comment #10 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-01-17
17:35:44 UTC ---
This looks like a problem totally unrelated to libitm and friends. The ICE
happens because dyld_stub___cxa_allocate_exception() is returning 0, which then
gets dereferenced. For that matter, it happens on a plain C++ program
compiling and linking the way dejagnu is setting things up:
Yanory-Hernandezs-MacBook:testsuite aldyh$ cat a.C
static void f1(){
throw 1;
}
int main()
{
try {
f1();
} catch (...) {
}
}
Yanory-Hernandezs-MacBook:testsuite aldyh$ /Users/aldyh/bld/1/gcc/xgcc
-B/Users/aldyh/bld/1/gcc/ a.C
-B/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/./libitm/
-I/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/./libitm
-I/mnt/gcc/libitm/testsuite/.. -shared-libgcc -fmessage-length=0 -fgnu-tm
-nostdinc++
-I/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/libstdc++-v3/include/x86_64-apple-darwin10.8.0
-I/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/libstdc++-v3/include
-I/mnt/gcc/libstdc++-v3/libsupc++ -I/mnt/gcc/libstdc++-v3/include/backward
-I/mnt/gcc/libstdc++-v3/testsuite/util
-L/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/./libitm/.libs
-L/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/./libitm/../libstdc++-v3/src/.libs
-shared-libgcc -lstdc++ -lm -g -o ./a.out
Yanory-Hernandezs-MacBook:testsuite aldyh$ ./a.out
Segmentation fault
(gdb) b f1
Breakpoint 1 at 0x10890: file a.C, line 2.
(gdb) disp/i $pc
(gdb) r
Starting program:
/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/libitm/testsuite/a.out
Reading symbols for shared libraries . done
Breakpoint 1, 0x00010890 in f1 () at a.C:2
2throw 1;
1: x/i $pc 0x10890 f1+4:mov$0x4,%edi
(gdb) si
0x000108952throw 1;
1: x/i $pc 0x10895 f1+9:callq 0x109ae
dyld_stub___cxa_allocate_exception
(gdb)
0x000109ae in dyld_stub___cxa_allocate_exception ()
1: x/i $pc 0x109ae dyld_stub___cxa_allocate_exception:jmpq
*0x68c(%rip)# 0x11040
(gdb)
0x000108e0 in __cxa_allocate_exception ()
1: x/i $pc 0x108e0 __cxa_allocate_exception:xor%eax,%eax
(gdb)
0x000108e2 in __cxa_allocate_exception ()
1: x/i $pc 0x108e2 __cxa_allocate_exception+2:retq
(gdb)
0x0001089a in f1 () at a.C:2
2throw 1;
1: x/i $pc 0x1089a f1+14:movl $0x1,(%rax)
(gdb)
Investigating whether this __cxa_allocation_exception() is coming from
trunk/libstdc++-v3 or from the system libstdc++...
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added CC||echristo at gcc dot ||gnu.org, stanshebs at ||earthlink dot net --- Comment #11 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-01-17 18:24:40 UTC --- Do any of the Darwin maintainers (or anyone else) know how to proceed from here? For some reason, while running the testsuite for libitm (as shown in comment#10), the stub for __cxa_allocate_exception is just a return 0. Even a simple C++ program doing a throw, calls this invalid stub. Is dejagnu building executables incorrectly in libitm? Or is there something else going on?
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #12 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-01-17
18:43:45 UTC ---
BTW, the reason this works when forcing the instrumented path as Torvald
suggested (comment #7) is because when f1() is instrumented, the call to
__cxa_allocate_exception is also instrumented and we actually call:
dyld_stub__ITM_cxa_allocate_exception() - _ITM_cxa_allocate_exception, which
is defined in libitm/eh_cpp.cc:
void *
_ITM_cxa_allocate_exception (size_t size)
{
void *r = __cxa_allocate_exception (size);
gtm_thr()-cxa_unthrown = r;
return r;
}
Assembly single stepping through the above shows that the call to
__cxa_allocate_exception (through dyld_stub___cxa_allocate_exception) has a
correct stub, not this return 0 nonsense I describe in comment #10.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 Eric Christopher echristo at gmail dot com changed: What|Removed |Added CC||echristo at gmail dot com --- Comment #13 from Eric Christopher echristo at gmail dot com 2013-01-17 22:17:16 UTC --- You can use DYLD_PRINT_BINDINGS to find out which __cxa_allocate_exception call is being used, it'll also give you the addresses so you can make sure that the right one is being called as you step through.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #9 from Richard Henderson rth at gcc dot gnu.org 2013-01-15 19:13:44 UTC --- Unfortunately, the gdb trace in #c1 isn't enough to see what's actually failing. What *ought* to be happening is that the uninstrumented code path runs, f1 makes two calls into the normal c++ runtime to (1) allocate the memory for the thrown int, and (2) actually throw the exception. Then we reach a cleanup inside f2 that calls _ITM_commitTransactionEH which commits the transaction (which will never fail, since we're in serial mode, since we're running the uninstrumented code path). Then we return from _ITM_cTEH and continue propagation of the exception, reaching main. This is exactly what happens under linux. What needs to happen at this point is a more detailed trace of f1 beginning at the line containing the throw. Given that EH is involved, this might require display/i $pc and stepi to avoid losing control. At the moment we have no idea even which runtime library is generating the fault.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 torvald at gcc dot gnu.org changed: What|Removed |Added CC||torvald at gcc dot gnu.org --- Comment #7 from torvald at gcc dot gnu.org 2013-01-11 22:54:04 UTC --- The gdb trace looks alright to me. My guess is that this is a bug in the uninstrumented code path, not in libitm. Could you try again after adding the following to the top of GTM::gtm_thread::begin_transaction in beginend.cc, please: prop = ~pr_uninstrumentedCode; Then, libitm shouldn't take the uninstrumented code path anymore. If it works with this change, this likely is a bug on the compiler side.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #8 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-12 03:24:55 UTC --- (In reply to comment #7) The gdb trace looks alright to me. My guess is that this is a bug in the uninstrumented code path, not in libitm. Could you try again after adding the following to the top of GTM::gtm_thread::begin_transaction in beginend.cc, please: prop = ~pr_uninstrumentedCode; Then, libitm shouldn't take the uninstrumented code path anymore. If it works with this change, this likely is a bug on the compiler side. Adding this line eliminates the testsuite failure on x86_64-apple-darwin12.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-14 Target Milestone|--- |4.8.0 Summary|regression in |[4.8 Regression] |libitm.c++/eh-1.C execution |libitm.c++/eh-1.C execution |test on darwin from r193271 |test fails on darwin from ||r193271 Ever Confirmed|0 |1 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-12-14 21:23:53 UTC --- Confirmed.
