[Bug libitm/55693] New: libitm.c++/eh-1.C execution test on darwin from r193271

[Bug libitm/55693] New: libitm.c++/eh-1.C execution test on darwin from r193271

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693

             Bug #: 55693
           Summary: libitm.c++/eh-1.C execution test on darwin from
                    r193271
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libitm
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: howarth@nitro.med.uc.edu


The commit of...

Author: rth
Date: Tue Nov  6 23:55:39 2012
New Revision: 193271

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193271
Log:
tm: Add uninstrumented code path

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cfg-flags.def
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/c-c++-common/tm/trxn-expr-3.c
    trunk/gcc/testsuite/gcc.dg/tm/debug-1.c
    trunk/gcc/testsuite/gcc.dg/tm/irrevocable-3.c
    trunk/gcc/testsuite/gcc.dg/tm/irrevocable-4.c
    trunk/gcc/testsuite/gcc.dg/tm/memopt-10.c
    trunk/gcc/testsuite/gcc.dg/tm/memopt-11.c
    trunk/gcc/testsuite/gcc.dg/tm/props-4.c
    trunk/gcc/testsuite/gcc.dg/tm/wrap-3.c
    trunk/gcc/testsuite/gcc.dg/tm/wrap-4.c
    trunk/gcc/trans-mem.c
    trunk/gcc/trans-mem.h
    trunk/gcc/tree-cfg.c

introduced the regression...

FAIL: libitm.c++/eh-1.C execution test

at -m32/-m64 on x86_64-apple-darwin*. The attached eh-1-gdb-trace.log contains
a stepwise walk from main until the segfault. The issue doesn't exist at
r193270.

Note that r193279 has to be applied at r193270 or r193271 to fix the bootstrap.

[Bug libitm/55693] libitm.c++/eh-1.C execution test on darwin from r193271

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693

--- Comment #1 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-12-14 18:54:43 UTC ---
Created attachment 28961
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28961
gdb stepwise walk of failing eh-1.exe from current gcc trunk on
x86_64-apple-darwin12

[Bug libitm/55693] regression in libitm.c++/eh-1.C execution test on darwin from r193271

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693

--- Comment #2 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-12-14 19:35:01 UTC ---
Created attachment 28964
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28964
assembly file for libitm.c++/eh-1.C on x86_64-apple-darwin12

Generated with...

/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/libitm/testsuite/libitm.c++/eh-1.C
-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/./libitm/
-I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/./libitm
-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/libitm/testsuite/..
-shared-libgcc -fmessage-length=0 -fgnu-tm -nostdinc++
-I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/include/x86_64-apple-darwin12.2.0
-I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/include
-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/libstdc++-v3/testsuite/util
-L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/./libitm/.libs
-L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/./libitm/../libstdc++-v3/src/.libs
-shared-libgcc -lstdc++ -lm -m64 -o ./eh-1.exe --save-temps

[Bug libitm/55693] regression in libitm.c++/eh-1.C execution test on darwin from r193271

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693

--- Comment #3 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-12-14 19:39:14 UTC ---
This issue is not triggered on x86_64 linux when building with --enable-tls=no
in order to use emutls like darwin.

[Bug libitm/55693] regression in libitm.c++/eh-1.C execution test on darwin from r193271

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dominiq at lps dot ens.fr

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-12-14 19:54:15 UTC ---
*** Bug 55648 has been marked as a duplicate of this bug. ***

[Bug libitm/55693] regression in libitm.c++/eh-1.C execution test on darwin from r193271

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693

--- Comment #5 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-12-14 20:30:26 UTC ---
Appending -fsanitize=address to the compilation of the failing eh-1.exe
testcase on x86_64-apple-darwin10 produces the following output on execution of
eh-1.exe...

ASAN:SIGSEGV
=================================================================
==79170== ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc
0x000100001497 sp 0x7fff5fbfded0 bp 0x7fff5fbfdee0 T0)
AddressSanitizer can not provide additional info.
    #0 0x100001496
(/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/libitm/testsuite/./eh-1.exe+0x100001496)
    #1 0x1000014e3
(/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/libitm/testsuite/./eh-1.exe+0x1000014e3)
    #2 0x10000154e
(/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/libitm/testsuite/./eh-1.exe+0x10000154e)
    #3 0x100001423
(/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/libitm/testsuite/./eh-1.exe+0x100001423)
    #4 0x0
(/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/libitm/testsuite/./eh-1.exe+0x0)
Stats: 0M malloced (0M for red zones) by 6 calls
Stats: 0M realloced by 0 calls
Stats: 0M freed by 0 calls
Stats: 0M really freed by 0 calls
Stats: 2M (513 full pages) mmaped in 4 calls
  mmaps   by size class: 9:1023; 10:511; 11:255; 13:64; 
  mallocs by size class: 9:2; 10:2; 11:1; 13:1; 
  frees   by size class: 
  rfrees  by size class: 
Stats: malloc large: 0 small slow: 4
==79170== ABORTING

whereas appending -fsanitize=address on x86_64 linux produces no output on
normal execution of the non-failing testcase with emutls.

[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271

[dominiq at lps dot ens.fr]

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.

[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271

[torvald at gcc dot gnu.org]

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

[howarth at nitro dot med.uc.edu]

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

[rth at gcc dot gnu.org]

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

[aldyh at gcc dot gnu.org]

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 0x100000890: 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, 0x0000000100000890 in f1 () at a.C:2
2    throw 1;
1: x/i $pc  0x100000890 <f1+4>:    mov    $0x4,%edi
(gdb) si
0x0000000100000895    2    throw 1;
1: x/i $pc  0x100000895 <f1+9>:    callq  0x1000009ae
<dyld_stub___cxa_allocate_exception>
(gdb) 
0x00000001000009ae in dyld_stub___cxa_allocate_exception ()
1: x/i $pc  0x1000009ae <dyld_stub___cxa_allocate_exception>:    jmpq  
*0x68c(%rip)        # 0x100001040
(gdb) 
0x00000001000008e0 in __cxa_allocate_exception ()
1: x/i $pc  0x1000008e0 <__cxa_allocate_exception>:    xor    %eax,%eax
(gdb) 
0x00000001000008e2 in __cxa_allocate_exception ()
1: x/i $pc  0x1000008e2 <__cxa_allocate_exception+2>:    retq   
(gdb) 
0x000000010000089a in f1 () at a.C:2
2    throw 1;
1: x/i $pc  0x10000089a <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

[aldyh at gcc dot gnu.org]

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

[aldyh at gcc dot gnu.org]

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

[echristo at gmail dot com]

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

[aldyh at redhat dot com]

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 
= 0x100000960
dyld: bind: libitm.1.dylib:0x100157018 = eh-1.exe:__ZdlPv, *0x100157018 
= 0x100000940
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:0x100001010 = libstdc++.6.dylib:__ZTIi, 
*0x100001010 = 0x1000AE2C0
dyld: bind: eh-1.exe:0x100001028 = 
libstdc++.6.dylib:___gxx_personality_v0, *0x100001028 = 0x1000059D0
dyld: bind: eh-1.exe:0x100001020 = 
libitm.1.dylib:__ITM_deregisterTMCloneTable, *0x100001020 = 0x10013FED7
dyld: bind: eh-1.exe:0x100001018 = 
libitm.1.dylib:__ITM_registerTMCloneTable, *0x100001018 = 0x10013FE45
dyld: bind: eh-1.exe:0x100001000 = libSystem.B.dylib:dyld_stub_binder, 
*0x100001000 = 0x7FFF80F46F94
dyld: weak bind: libstdc++.6.dylib:0x1000AD010 = eh-1.exe:__ZdaPv, 
*0x1000AD010 = 0x100000960
dyld: weak bind: libstdc++.6.dylib:0x1000AD458 = eh-1.exe:__ZdaPv, 
*0x1000AD458 = 0x100000960
dyld: weak bind: libstdc++.6.dylib:0x1000AD460 = eh-1.exe:__ZdlPv, 
*0x1000AD460 = 0x100000940
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:0x100001080 = libSystem.B.dylib:_dladdr, 
*0x100001080 = 0x7FFF80E44D9A
dyld: lazy bind: eh-1.exe:0x100001090 = 
libSystem.B.dylib:_getsectdatafromheader_64, *0x100001090 = 0x7FFF80E44BA6

[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271

[aldyh at gcc dot gnu.org]

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

[howarth at nitro dot med.uc.edu]

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

[howarth at nitro dot med.uc.edu]

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 0x100001764: 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, 0x0000000100001764 in f1 () at a.C:2
2    throw 1;
1: x/i $pc  0x100001764 <f1+4>:    mov    $0x4,%edi
(gdb) si
0x0000000100001769    2    throw 1;
1: x/i $pc  0x100001769 <f1+9>:    callq  0x10000a680
<__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  0x10000a680 <__cxa_allocate_exception>:    push   %rbp
(gdb) 
105      thrown_size += sizeof (__cxa_refcounted_exception);
1: x/i $pc  0x10000a681 <__cxa_allocate_exception+1>:    lea    0x80(%rdi),%rbp
(gdb) 
102    {
1: x/i $pc  0x10000a688 <__cxa_allocate_exception+8>:    push   %rbx
(gdb) 
106      ret = malloc (thrown_size);
1: x/i $pc  0x10000a689 <__cxa_allocate_exception+9>:    mov    %rbp,%rdi
(gdb) 
102    {
1: x/i $pc  0x10000a68c <__cxa_allocate_exception+12>:    sub    $0x8,%rsp
(gdb) 
106      ret = malloc (thrown_size);
1: x/i $pc  0x10000a690 <__cxa_allocate_exception+16>:    callq  0x10001f960
<dyld_stub_malloc>
(gdb) 
0x000000010001f960 in dyld_stub_malloc ()
1: x/i $pc  0x10001f960 <dyld_stub_malloc>:    jmpq   *0xc7aa(%rip)        #
0x10002c110
(gdb) 
0x000000010001fad0 in dyld_stub___cxa_tm_cleanup ()
1: x/i $pc  0x10001fad0:    pushq  $0x1d3
(gdb) 
0x000000010001fad5 in dyld_stub___cxa_tm_cleanup ()
1: x/i $pc  0x10001fad5:    jmpq   0x10001f9f8
(gdb) 
0x000000010001f9f8 in dyld_stub___cxa_tm_cleanup ()
1: x/i $pc  0x10001f9f8:    lea    0xc661(%rip),%r11        # 0x10002c060
(gdb) 
0x000000010001f9ff in dyld_stub___cxa_tm_cleanup ()
1: x/i $pc  0x10001f9ff:    push   %r11
(gdb) 
0x000000010001fa01 in dyld_stub___cxa_tm_cleanup ()
1: x/i $pc  0x10001fa01:    jmpq   *0xc651(%rip)        # 0x10002c058
(gdb) 
0x00007fff847c9878 in dyld_stub_binder ()
1: x/i $pc  0x7fff847c9878 <dyld_stub_binder>:    push   %rbp
(gdb) 
0x00007fff847c9879 in dyld_stub_binder ()
1: x/i $pc  0x7fff847c9879 <dyld_stub_binder+1>:    mov    %rsp,%rbp
(gdb) 
0x00007fff847c987c in dyld_stub_binder ()
1: x/i $pc  0x7fff847c987c <dyld_stub_binder+4>:    sub    $0xc0,%rsp
(gdb) 
0x00007fff847c9883 in dyld_stub_binder ()
1: x/i $pc  0x7fff847c9883 <dyld_stub_binder+11>:    mov    %rdi,(%rsp)
(gdb) 
0x00007fff847c9887 in dyld_stub_binder ()
1: x/i $pc  0x7fff847c9887 <dyld_stub_binder+15>:    mov    %rsi,0x8(%rsp)
(gdb) 
0x00007fff847c988c in dyld_stub_binder ()
1: x/i $pc  0x7fff847c988c <dyld_stub_binder+20>:    mov    %rdx,0x10(%rsp)
(gdb) 
0x00007fff847c9891 in dyld_stub_binder ()
1: x/i $pc  0x7fff847c9891 <dyld_stub_binder+25>:    mov    %rcx,0x18(%rsp)
(gdb) 
0x00007fff847c9896 in dyld_stub_binder ()
1: x/i $pc  0x7fff847c9896 <dyld_stub_binder+30>:    mov    %r8,0x20(%rsp)
(gdb) 
0x00007fff847c989b in dyld_stub_binder ()
1: x/i $pc  0x7fff847c989b <dyld_stub_binder+35>:    mov    %r9,0x28(%rsp)
(gdb) 
0x00007fff847c98a0 in dyld_stub_binder ()
1: x/i $pc  0x7fff847c98a0 <dyld_stub_binder+40>:    mov    %rax,0x30(%rsp)
(gdb) 
0x00007fff847c98a5 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

[howarth at nitro dot med.uc.edu]

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

[howarth at nitro dot med.uc.edu]

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

[aldyh at gcc dot gnu.org]

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

[iains at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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

[dominiq at lps dot ens.fr]

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

[iains at gcc dot gnu.org]

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

[aldyh at redhat dot com]

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

[howarth at nitro dot med.uc.edu]

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

[howarth at nitro dot med.uc.edu]

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

[howarth at nitro dot med.uc.edu]

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

[dominiq at lps dot ens.fr]

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

[howarth at nitro dot med.uc.edu]

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

[howarth at nitro dot med.uc.edu]

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

[iains at gcc dot gnu.org]

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

[iains at gcc dot gnu.org]

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

[iains at gcc dot gnu.org]

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
00000100 (__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

[howarth at nitro dot med.uc.edu]

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

[howarth at nitro dot med.uc.edu]

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

[iains at gcc dot gnu.org]

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

[howarth at nitro dot med.uc.edu]

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

[iains at gcc dot gnu.org]

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

[howarth at nitro dot med.uc.edu]

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

[howarth at nitro dot med.uc.edu]

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

[howarth at nitro dot med.uc.edu]

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

[mrs at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693

mrs@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

[howarth at nitro dot med.uc.edu]

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

[dominiq at lps dot ens.fr]

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

[patrick.marlier at gmail dot com]

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

[howarth at nitro dot med.uc.edu]

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

[howarth at nitro dot med.uc.edu]

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

[howarth at nitro dot med.uc.edu]

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

[howarth at nitro dot med.uc.edu]

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

[mrs at gcc dot gnu.org]

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=gcc&view=rev&rev=195960
Log:
/libgcc
2013-02-11  Iain Sandoe  <iain@codesourcery.com>
        Jack Howarth  <howarth@bromo.med.uc.edu>
        Patrick Marlier  <patrick.marlier@gmail.com>

    PR libitm/55693
    * config/darwin-crt-tm.c: Remove dummy functions hack.

/gcc
2013-02-11  Iain Sandoe  <iain@codesourcery.com>
        Jack Howarth  <howarth@bromo.med.uc.edu>
        Patrick Marlier  <patrick.marlier@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  <iain@codesourcery.com>
        Jack Howarth  <howarth@bromo.med.uc.edu>
        Patrick Marlier  <patrick.marlier@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

[mrs at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693

mrs@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.