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
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
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
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
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
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
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
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
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
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
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
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
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,
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://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
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
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
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
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.
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
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
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
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
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
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
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?
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
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
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
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
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
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
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()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
Aldy Hernandez aldyh at gcc dot gnu.org changed:
What|Removed |Added
CC|
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.
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
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
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:
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
Aldy Hernandez aldyh at gcc dot gnu.org changed:
What|Removed |Added
CC||echristo
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
Eric Christopher echristo at gmail dot com changed:
What|Removed |Added
CC|
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
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
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.
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
47 matches
Mail list logo
