Compiling g-exptty.adb on x86_64-apple-darwin16 at r247343 fails with /opt/gcc/build_a/./gcc/xgcc -B/opt/gcc/build_a/./gcc/ -B/opt/gcc/gcc8a/x86_64-apple-darwin16.5.0/bin/ -B/opt/gcc/gcc8a/x86_64-apple-darwin16.5.0/lib/ -isystem /opt/gcc/gcc8a/x86_64-apple-darwin16.5.0/include -isystem /opt/gcc/gcc8a/x86_64-apple-darwin16.5.0/sys-include -c -g -O2 -fno-common -W -Wall -gnatpg -nostdinc g-exptty.adb -o g-exptty.o xgcc: internal compiler error: Illegal instruction: 4 (program gnat1) and breaks bootstrap. Revision r247285 is OK.
Not fixed at revision r247391.
Other native platforms seem fine, so please post a backtrace.
> Other native platforms seem fine, so please post a backtrace. The best I can do without further directives: [Book15] ada/rts% lldb /opt/gcc/build_a/gcc/gnat1 (lldb) run -O2 g-exptty.adb Process 95815 launched: '/opt/gcc/build_a/gcc/gnat1' (x86_64) Process 95815 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT frame #0: 0x00007fffa7e8fd42 libsystem_kernel.dylib`__pthread_kill + 10 libsystem_kernel.dylib`__pthread_kill: -> 0x7fffa7e8fd42 <+10>: jae 0x7fffa7e8fd4c ; <+20> 0x7fffa7e8fd44 <+12>: movq %rax, %rdi 0x7fffa7e8fd47 <+15>: jmp 0x7fffa7e88caf ; cerror_nocancel 0x7fffa7e8fd4c <+20>: retq (lldb) bt error: gnat1 {0x00179120}: unhandled type tag 0x0021 (DW_TAG_subrange_type), please file a bug and attach the file at the start of this error message ... a bunch of similar errors ... * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT * frame #0: 0x00007fffa7e8fd42 libsystem_kernel.dylib`__pthread_kill + 10 frame #1: 0x00007fffa7f7d5bf libsystem_pthread.dylib`pthread_kill + 90 frame #2: 0x00007fffa7df5420 libsystem_c.dylib`abort + 129 frame #3: 0x0000000100ff88c1 gnat1`uw_init_context_1(context=<unavailable>, outer_cfa=<unavailable>, outer_ra=<unavailable>) at unwind-dw2.c:1579 frame #4: 0x0000000100ff8f2e gnat1`_Unwind_RaiseException(exc=0x0000000144a022a0) at unwind.inc:88 frame #5: 0x000000010006663f gnat1`ada__exceptions__exception_propagation__propagate_gcc_exceptionXn(gcc_exception=0x0000000144a022a0) at a-exexpr.adb:322 frame #6: 0x0000000100066683 gnat1`ada__exceptions__exception_propagation__propagate_exceptionXn(excep=<unavailable>) at a-exexpr.adb:354 frame #7: 0x0000000100066af9 gnat1`ada__exceptions__complete_and_propagate_occurrence(x=<unavailable>) at a-except.adb:937 frame #8: 0x0000000100066b2e gnat1`__gnat_raise_exception(e=<unavailable>, message=<unavailable>) at a-except.adb:978 frame #9: 0x00000001001fbf9a gnat1`rtsfind__load_fail(s=const string___XUP @ 0x00007fe1c0cf6f50, u_id=<unavailable>, id=<unavailable>) at rtsfind.adb:851 frame #10: 0x00000001001fc316 gnat1`rtsfind__load_rtu(u_id=<unavailable>, id=<unavailable>, use_setting=<unavailable>) at rtsfind.adb:987 frame #11: 0x00000001001fc74e gnat1`rtsfind__rte at rtsfind.adb:1380 frame #12: 0x00000001001fcab8 gnat1`rtsfind__rte_available(e=<unavailable>) at rtsfind.adb:1462 frame #13: 0x000000010011d4ad gnat1`exp_ch9__expand_n_delay_relative_statement(n=<no summary available>) at exp_ch9.adb:8068 frame #14: 0x000000010017078f gnat1`expander__expand(n=<no summary available>) at expander.adb:214 frame #15: 0x00000001002124d8 gnat1`sem__analyze(n=<no summary available>) at sem.adb:753 frame #16: 0x000000010029d347 gnat1`sem_ch5__analyze_statements(l=<no summary available>) at sem_ch5.adb:3613 frame #17: 0x000000010029f06e gnat1`sem_ch5__analyze_if_statement(n=<no summary available>) at sem_ch5.adb:1665 frame #18: 0x0000000100212bf0 gnat1`sem__analyze(n=<no summary available>) at sem.adb:306 frame #19: 0x000000010029d347 gnat1`sem_ch5__analyze_statements(l=<no summary available>) at sem_ch5.adb:3613 frame #20: 0x00000001002396ee gnat1`sem_ch11__analyze_handled_statements(n=<no summary available>) at sem_ch11.adb:426 frame #21: 0x0000000100212882 gnat1`sem__analyze(n=<no summary available>) at sem.adb:297 frame #22: 0x00000001002ad694 gnat1`sem_ch6__analyze_subprogram_body(n=<unavailable>) at sem_ch6.adb:4245 frame #23: 0x0000000100212ace gnat1`sem__analyze(n=<no summary available>) at sem.adb:547 frame #24: 0x000000010027767b gnat1`sem_ch3__analyze_declarations(l=<no summary available>) at sem_ch3.adb:2608 frame #25: 0x00000001002b2dbe gnat1`sem_ch7__analyze_package_body(n=<no summary available>) at sem_ch7.adb:786 frame #26: 0x0000000100212ada gnat1`sem__analyze(n=<no summary available>) at sem.adb:444 frame #27: 0x0000000100236c22 gnat1`sem_ch10__analyze_compilation_unit(n=<no summary available>) at sem_ch10.adb:897 frame #28: 0x0000000100212713 gnat1`sem__analyze(n=<no summary available>) at sem.adb:180 frame #29: 0x0000000100213863 gnat1`sem__semantics at sem.adb:1338 frame #30: 0x00000001002137e6 gnat1`sem__semantics frame #31: 0x0000000100182fd4 gnat1`_ada_frontend at frontend.adb:407 frame #32: 0x000000010037a6b1 gnat1`_ada_gnat1drv at gnat1drv.adb:1127 frame #33: 0x000000010001daff gnat1`::gnat_parse_file() at misc.c:122 frame #34: 0x0000000100c583ca gnat1`::compile_file() at toplev.c:467 frame #35: 0x0000000100ffd717 gnat1`toplev::main(int, char**) at toplev.c:2003 frame #36: 0x0000000100ffd227 gnat1`toplev::main(this=0x00007fff5fbff2fe, argc=<unavailable>, argv=<unavailable>) frame #37: 0x0000000100fff2fe gnat1`main(argc=3, argv=0x00007fff5fbff330) at main.c:39 frame #38: 0x00007fffa7d61235 libdyld.dylib`start + 1
> a bunch of similar errors > ... > * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT > * frame #0: 0x00007fffa7e8fd42 libsystem_kernel.dylib`__pthread_kill + 10 > frame #1: 0x00007fffa7f7d5bf libsystem_pthread.dylib`pthread_kill + 90 > frame #2: 0x00007fffa7df5420 libsystem_c.dylib`abort + 129 > frame #3: 0x0000000100ff88c1 > gnat1`uw_init_context_1(context=<unavailable>, outer_cfa=<unavailable>, > outer_ra=<unavailable>) at unwind-dw2.c:1579 > frame #4: 0x0000000100ff8f2e > gnat1`_Unwind_RaiseException(exc=0x0000000144a022a0) at unwind.inc:88 > frame #5: 0x000000010006663f > gnat1`ada__exceptions__exception_propagation__propagate_gcc_exceptionXn(gcc_e > xception=0x0000000144a022a0) at a-exexpr.adb:322 > frame #6: 0x0000000100066683 > gnat1`ada__exceptions__exception_propagation__propagate_exceptionXn(excep=<un > available>) at a-exexpr.adb:354 > frame #7: 0x0000000100066af9 > gnat1`ada__exceptions__complete_and_propagate_occurrence(x=<unavailable>) at > a-except.adb:937 > frame #8: 0x0000000100066b2e > gnat1`__gnat_raise_exception(e=<unavailable>, message=<unavailable>) at > a-except.adb:978 > frame #9: 0x00000001001fbf9a gnat1`rtsfind__load_fail(s=const > string___XUP @ 0x00007fe1c0cf6f50, u_id=<unavailable>, id=<unavailable>) at > rtsfind.adb:851 OK, thanks, there is a problem in exception propagation on the Darwin host. I'm not exactly a specialist here, so CCing Tristan.
The last successful bootstrap is r247298; r247301 fails as reported in comment 0; r247299 fails for a different reason: /opt/gcc/p_build/./gcc/xgcc -B/opt/gcc/p_build/./gcc/ -B/opt/gcc/gcc8p-247299p1/x86_64-apple-darwin16.5.0/bin/ -B/opt/gcc/gcc8p-247299p1/x86_64-apple-darwin16.5.0/lib/ -isystem /opt/gcc/gcc8p-247299p1/x86_64-apple-darwin16.5.0/include -isystem /opt/gcc/gcc8p-247299p1/x86_64-apple-darwin16.5.0/sys-include -c -g -O2 -fno-common -W -Wall -gnatpg -nostdinc s-excmac.ads -o s-excmac.o cannot generate code for file s-excmac.ads (package spec)
On 29/04/2017 21:11, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556 > > Eric Botcazou <ebotcazou at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|WAITING |NEW > CC| |gingold at gcc dot gnu.org > > --- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- >> a bunch of similar errors >> ... >> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT >> * frame #0: 0x00007fffa7e8fd42 libsystem_kernel.dylib`__pthread_kill + 10 >> frame #1: 0x00007fffa7f7d5bf libsystem_pthread.dylib`pthread_kill + 90 >> frame #2: 0x00007fffa7df5420 libsystem_c.dylib`abort + 129 >> frame #3: 0x0000000100ff88c1 >> gnat1`uw_init_context_1(context=<unavailable>, outer_cfa=<unavailable>, >> outer_ra=<unavailable>) at unwind-dw2.c:1579 >> frame #4: 0x0000000100ff8f2e >> gnat1`_Unwind_RaiseException(exc=0x0000000144a022a0) at unwind.inc:88 >> frame #5: 0x000000010006663f >> gnat1`ada__exceptions__exception_propagation__propagate_gcc_exceptionXn(gcc_e >> xception=0x0000000144a022a0) at a-exexpr.adb:322 >> frame #6: 0x0000000100066683 >> gnat1`ada__exceptions__exception_propagation__propagate_exceptionXn(excep=<un >> available>) at a-exexpr.adb:354 >> frame #7: 0x0000000100066af9 >> gnat1`ada__exceptions__complete_and_propagate_occurrence(x=<unavailable>) at >> a-except.adb:937 >> frame #8: 0x0000000100066b2e >> gnat1`__gnat_raise_exception(e=<unavailable>, message=<unavailable>) at >> a-except.adb:978 >> frame #9: 0x00000001001fbf9a gnat1`rtsfind__load_fail(s=const >> string___XUP @ 0x00007fe1c0cf6f50, u_id=<unavailable>, id=<unavailable>) at >> rtsfind.adb:851 > > OK, thanks, there is a problem in exception propagation on the Darwin host. > I'm not exactly a specialist here, so CCing Tristan. It looks like gnat1 was compiled with libgcc, which is not able to handle unwinding on Darwin. I suppose it must be linked without -static-libgcc >
> It looks like gnat1 was compiled with libgcc, which is not able to > handle unwinding on Darwin. > I suppose it must be linked without -static-libgcc Is there a specific change intended to do it and which doesn't work here?
> It looks like gnat1 was compiled with libgcc, which is not able to > handle unwinding on Darwin. > I suppose it must be linked without -static-libgcc This was handled properly on darwin up to r247298. The changes in r247301 should be updated to work properly on darwin.
PR80590 could be a non-darwin duplicate.
Interestingly, a i386-apple-darwin16 bootstrap *does* work fine.
Any chance to see this PR fixed soon?
On 09/05/2017 14:43, dominiq at lps dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556 > > --- Comment #11 from Dominique d'Humieres <dominiq at lps dot ens.fr> --- > Any chance to see this PR fixed soon? Did you try to get gnat1 built without -static-libgcc ?
> Did you try to get gnat1 built without -static-libgcc ? How am I supposed to do that? I have used the same clean configure ../p_work/configure --prefix=/opt/gcc/gcc8p-247298p1 --enable-languages=c,c++,lto,fortran,ada,objc,obj-c++ --with-gmp=/opt/mp-new --with-system-zlib --enable-checking=release --with-isl=/opt/mp-new --enable-lto --enable-plugin --with-arch=corei7 --with-cpu=corei7 and bootstrap for r247298 (bootstraps) and r247302 (fails). The bootstrap compiler is gcc version 8.0.0 20170425 (experimental) [trunk revision 247256] configured with ../_clean/configure --prefix=/opt/gcc/gcc8a --enable-languages=c,c++,fortran,ada,lto --with-gmp=/opt/mp-new --with-system-zlib --enable-checking=release --with-isl=/opt/mp-new --enable-lto --enable-plugin
On 09/05/2017 15:14, dominiq at lps dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556 > > --- Comment #13 from Dominique d'Humieres <dominiq at lps dot ens.fr> --- >> Did you try to get gnat1 built without -static-libgcc ? > > How am I supposed to do that? I have used the same clean configure > > ../p_work/configure --prefix=/opt/gcc/gcc8p-247298p1 > --enable-languages=c,c++,lto,fortran,ada,objc,obj-c++ --with-gmp=/opt/mp-new > --with-system-zlib --enable-checking=release --with-isl=/opt/mp-new > --enable-lto --enable-plugin --with-arch=corei7 --with-cpu=corei7 > > and bootstrap for r247298 (bootstraps) and r247302 (fails). > > The bootstrap compiler is > > gcc version 8.0.0 20170425 (experimental) [trunk revision 247256] > > configured with > > ../_clean/configure --prefix=/opt/gcc/gcc8a > --enable-languages=c,c++,fortran,ada,lto --with-gmp=/opt/mp-new > --with-system-zlib --enable-checking=release --with-isl=/opt/mp-new > --enable-lto --enable-plugin You should add: --with-stage1-ldflags=-static-libstdc++ --with-boot-ldflags=-static-libstdc++ to your configure line.
> You should add: > > --with-stage1-ldflags=-static-libstdc++ > --with-boot-ldflags=-static-libstdc++ > > to your configure line. With these lines added to my configure line I have been able to bootstrap revision r247792. However this addition was not necessary before and I don't think it is the end user responsibility to do the addition.
> With these lines added to my configure line I have been able to bootstrap > revision r247792. However this addition was not necessary before and I don't > think it is the end user responsibility to do the addition. Right. Can you make the necessary modifications to the toplevel configure.ac for Darwin (grep for -static-libgcc) and post them on gcc-patches@?
On 09/05/2017 17:41, dominiq at lps dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556 > > --- Comment #15 from Dominique d'Humieres <dominiq at lps dot ens.fr> --- >> You should add: >> >> --with-stage1-ldflags=-static-libstdc++ >> --with-boot-ldflags=-static-libstdc++ >> >> to your configure line. > > With these lines added to my configure line I have been able to bootstrap > revision r247792. However this addition was not necessary before and I don't > think it is the end user responsibility to do the addition. This failure is simply a consequence of broken libgcc on Darwin: this libgcc is not able to get exception table addresses and therefore cannot propagate exceptions. Any program (that uses exceptions) and linked with -static-libgcc on Darwin will also fail.
> This failure is simply a consequence of broken libgcc on Darwin: this > libgcc is not able to get exception table addresses and therefore cannot > propagate exceptions. > > Any program (that uses exceptions) and linked with -static-libgcc on > Darwin will also fail. In the commit r247301 I see in gcc/ada/gcc-interface/Make-lang.in --- trunk/gcc/ada/gcc-interface/Make-lang.in 2017/04/27 09:44:28 247300 +++ trunk/gcc/ada/gcc-interface/Make-lang.in 2017/04/27 09:48:45 247301 @@ -99,6 +99,8 @@ ada-warn = $(ADA_CFLAGS) $(filter-out -pedantic, $(STRICT_WARN)) # Unresolved warnings in specific files. ada/adaint.o-warn = -Wno-error +# For unwind-pe.h +CFLAGS-ada/raise-gcc.o += -I$(srcdir)/../libgcc -Iinclude ada/%.o: ada/gcc-interface/%.c $(COMPILE) $< Isn't this wrong for darwin?
On 10/05/2017 18:04, dominiq at lps dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556 > In the commit r247301 I see in gcc/ada/gcc-interface/Make-lang.in > > --- trunk/gcc/ada/gcc-interface/Make-lang.in 2017/04/27 09:44:28 247300 > +++ trunk/gcc/ada/gcc-interface/Make-lang.in 2017/04/27 09:48:45 247301 > @@ -99,6 +99,8 @@ > ada-warn = $(ADA_CFLAGS) $(filter-out -pedantic, $(STRICT_WARN)) > # Unresolved warnings in specific files. > ada/adaint.o-warn = -Wno-error > +# For unwind-pe.h > +CFLAGS-ada/raise-gcc.o += -I$(srcdir)/../libgcc -Iinclude > > ada/%.o: ada/gcc-interface/%.c > $(COMPILE) $< > > Isn't this wrong for darwin? Why ? The header unwind-pe.h is needed for the personality routine.
(In reply to Tristan Gingold from comment #19) > On 10/05/2017 18:04, dominiq at lps dot ens.fr wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556 > > > In the commit r247301 I see in gcc/ada/gcc-interface/Make-lang.in > > > > --- trunk/gcc/ada/gcc-interface/Make-lang.in 2017/04/27 09:44:28 247300 > > +++ trunk/gcc/ada/gcc-interface/Make-lang.in 2017/04/27 09:48:45 247301 > > @@ -99,6 +99,8 @@ > > ada-warn = $(ADA_CFLAGS) $(filter-out -pedantic, $(STRICT_WARN)) > > # Unresolved warnings in specific files. > > ada/adaint.o-warn = -Wno-error > > +# For unwind-pe.h > > +CFLAGS-ada/raise-gcc.o += -I$(srcdir)/../libgcc -Iinclude > > > > ada/%.o: ada/gcc-interface/%.c > > $(COMPILE) $< > > > > Isn't this wrong for darwin? > > Why ? > > The header unwind-pe.h is needed for the personality routine. What we need to do is to remove the (use of) libgcc_s and not use libgcc_eh (static-libgcc) for Darwin > 10, since the unwinder is now in usr/lib/system/libunwind.dylib. Needs two chunks (1) move the content for TLS emulation somewhere else, since that's a reason to need libgcc_s (2) adjust the use of libgcc for Darwin > 10 to not include libgcc_eh for -static-libgcc. I have some patches for gcc-5 and 6 that do this, will forward-port them. I'm a little surprised that we need explicit -static-libstdc++ for gnat, the rest of the compiler already handles this?
On 11/05/2017 09:44, iains at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556 > > --- Comment #20 from Iain Sandoe <iains at gcc dot gnu.org> --- > (In reply to Tristan Gingold from comment #19) >> On 10/05/2017 18:04, dominiq at lps dot ens.fr wrote: >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556 >> >>> In the commit r247301 I see in gcc/ada/gcc-interface/Make-lang.in >>> >>> --- trunk/gcc/ada/gcc-interface/Make-lang.in 2017/04/27 09:44:28 247300 >>> +++ trunk/gcc/ada/gcc-interface/Make-lang.in 2017/04/27 09:48:45 247301 >>> @@ -99,6 +99,8 @@ >>> ada-warn = $(ADA_CFLAGS) $(filter-out -pedantic, $(STRICT_WARN)) >>> # Unresolved warnings in specific files. >>> ada/adaint.o-warn = -Wno-error >>> +# For unwind-pe.h >>> +CFLAGS-ada/raise-gcc.o += -I$(srcdir)/../libgcc -Iinclude >>> >>> ada/%.o: ada/gcc-interface/%.c >>> $(COMPILE) $< >>> >>> Isn't this wrong for darwin? >> >> Why ? >> >> The header unwind-pe.h is needed for the personality routine. > > What we need to do is to remove the (use of) libgcc_s and not use libgcc_eh > (static-libgcc) for Darwin > 10, since the unwinder is now in > usr/lib/system/libunwind.dylib. > > Needs two chunks (1) move the content for TLS emulation somewhere else, since > that's a reason to need libgcc_s (2) adjust the use of libgcc for Darwin > 10 > to not include libgcc_eh for -static-libgcc. I have some patches for gcc-5 and > 6 that do this, will forward-port them. Great! > I'm a little surprised that we need explicit -static-libstdc++ for gnat, the > rest of the compiler already handles this? We just need to remove -static-libgcc but keep -static-libstdc++
(In reply to Tristan Gingold from comment #21) > On 11/05/2017 09:44, iains at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556 > > > > --- Comment #20 from Iain Sandoe <iains at gcc dot gnu.org> --- > > (In reply to Tristan Gingold from comment #19) > >> On 10/05/2017 18:04, dominiq at lps dot ens.fr wrote: > >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556 > >> > >>> In the commit r247301 I see in gcc/ada/gcc-interface/Make-lang.in > >>> > >>> --- trunk/gcc/ada/gcc-interface/Make-lang.in 2017/04/27 09:44:28 247300 > >>> +++ trunk/gcc/ada/gcc-interface/Make-lang.in 2017/04/27 09:48:45 247301 > >>> @@ -99,6 +99,8 @@ > >>> ada-warn = $(ADA_CFLAGS) $(filter-out -pedantic, $(STRICT_WARN)) > >>> # Unresolved warnings in specific files. > >>> ada/adaint.o-warn = -Wno-error > >>> +# For unwind-pe.h > >>> +CFLAGS-ada/raise-gcc.o += -I$(srcdir)/../libgcc -Iinclude > >>> > >>> ada/%.o: ada/gcc-interface/%.c > >>> $(COMPILE) $< > >>> > >>> Isn't this wrong for darwin? > >> > >> Why ? > >> > >> The header unwind-pe.h is needed for the personality routine. > > > > What we need to do is to remove the (use of) libgcc_s and not use libgcc_eh > > (static-libgcc) for Darwin > 10, since the unwinder is now in > > usr/lib/system/libunwind.dylib. > > > > Needs two chunks (1) move the content for TLS emulation somewhere else, since > > that's a reason to need libgcc_s (2) adjust the use of libgcc for Darwin > 10 > > to not include libgcc_eh for -static-libgcc. I have some patches for gcc-5 and > > 6 that do this, will forward-port them. > > Great! .. but might not be 'this week' ;-) > > I'm a little surprised that we need explicit -static-libstdc++ for gnat, the > > rest of the compiler already handles this? > > We just need to remove -static-libgcc but keep -static-libstdc++ OK. So looking at the breaking rev. (and to check I've understood correctly) - the change switches gnat from using setjmp/longjmp to using DWARF unwinding (and thus exposes the incompatibility)? In the short-term, what ought to work is to ensure that -lSystem appears before any -lgcc on the link line (so that the correct unwinder is used), and to remove -static-libgcc. TBH static-libgcc should actually work unless gnat is now pulling in any other system libraries which cause two unwinders to be present - I guess it might be? (probably, as an aside, we ought to look at putting libstdc++ on top of libc++abi instead of libsupc++ - but that's on the TODO, no patches yet).
On 11/05/2017 10:11, iains at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556 > > --- Comment #22 from Iain Sandoe <iains at gcc dot gnu.org> --- > (In reply to Tristan Gingold from comment #21) >> On 11/05/2017 09:44, iains at gcc dot gnu.org wrote: >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556 >>> >>> --- Comment #20 from Iain Sandoe <iains at gcc dot gnu.org> --- >>> (In reply to Tristan Gingold from comment #19) >>>> On 10/05/2017 18:04, dominiq at lps dot ens.fr wrote: >>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556 >>>> >>>>> In the commit r247301 I see in gcc/ada/gcc-interface/Make-lang.in >>>>> >>>>> --- trunk/gcc/ada/gcc-interface/Make-lang.in 2017/04/27 09:44:28 247300 >>>>> +++ trunk/gcc/ada/gcc-interface/Make-lang.in 2017/04/27 09:48:45 247301 >>>>> @@ -99,6 +99,8 @@ >>>>> ada-warn = $(ADA_CFLAGS) $(filter-out -pedantic, $(STRICT_WARN)) >>>>> # Unresolved warnings in specific files. >>>>> ada/adaint.o-warn = -Wno-error >>>>> +# For unwind-pe.h >>>>> +CFLAGS-ada/raise-gcc.o += -I$(srcdir)/../libgcc -Iinclude >>>>> >>>>> ada/%.o: ada/gcc-interface/%.c >>>>> $(COMPILE) $< >>>>> >>>>> Isn't this wrong for darwin? >>>> >>>> Why ? >>>> >>>> The header unwind-pe.h is needed for the personality routine. >>> >>> What we need to do is to remove the (use of) libgcc_s and not use libgcc_eh >>> (static-libgcc) for Darwin > 10, since the unwinder is now in >>> usr/lib/system/libunwind.dylib. >>> >>> Needs two chunks (1) move the content for TLS emulation somewhere else, since >>> that's a reason to need libgcc_s (2) adjust the use of libgcc for Darwin > 10 >>> to not include libgcc_eh for -static-libgcc. I have some patches for gcc-5 and >>> 6 that do this, will forward-port them. >> >> Great! > > .. but might not be 'this week' ;-) > > >>> I'm a little surprised that we need explicit -static-libstdc++ for gnat, the >>> rest of the compiler already handles this? >> >> We just need to remove -static-libgcc but keep -static-libstdc++ > > OK. So looking at the breaking rev. (and to check I've understood correctly) - > the change switches gnat from using setjmp/longjmp to using DWARF unwinding > (and thus exposes the incompatibility)? Yes. > In the short-term, what ought to work is to ensure that -lSystem appears before > any -lgcc on the link line (so that the correct unwinder is used), and to > remove -static-libgcc. Might work too. > TBH static-libgcc should actually work unless gnat is now pulling in any other > system libraries which cause two unwinders to be present - I guess it might be? No, I think static-libgcc cannot work because it is not able to get the address of the unwind tables (on recent Darwin versions). > (probably, as an aside, we ought to look at putting libstdc++ on top of > libc++abi instead of libsupc++ - but that's on the TODO, no patches yet). Hum, yes.
> Le 11 mai 2017 à 09:06, gingold at adacore dot com <gcc-bugzilla@gcc.gnu.org> a écrit : > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556 > > --- Comment #19 from Tristan Gingold <gingold at adacore dot com> --- > On 10/05/2017 18:04, dominiq at lps dot ens.fr wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556 > >> In the commit r247301 I see in gcc/ada/gcc-interface/Make-lang.in >> >> --- trunk/gcc/ada/gcc-interface/Make-lang.in 2017/04/27 09:44:28 247300 >> +++ trunk/gcc/ada/gcc-interface/Make-lang.in 2017/04/27 09:48:45 247301 >> @@ -99,6 +99,8 @@ >> ada-warn = $(ADA_CFLAGS) $(filter-out -pedantic, $(STRICT_WARN)) >> # Unresolved warnings in specific files. >> ada/adaint.o-warn = -Wno-error >> +# For unwind-pe.h >> +CFLAGS-ada/raise-gcc.o += -I$(srcdir)/../libgcc -Iinclude >> >> ada/%.o: ada/gcc-interface/%.c >> $(COMPILE) $< >> >> Isn't this wrong for darwin? > > Why ? I cannot distinguish -I (for include) and -l (for libs) on my browser, hence the mistake. Note that --with-stage1-ldflags=-static-libstdc++ --with-boot-ldflags=-static-libstdc++ does not work if the install directory is empty: dyld: Symbol not found: __ZdlPvm Referenced from: /opt/gcc/p_build/gcc/build/genmddeps (which was built for Mac OS X 10.12) Expected in: /usr/lib/libstdc++.6.dylib in /opt/gcc/p_build/gcc/build/genmddeps Dominique > > The header unwind-pe.h is needed for the personality routine. > > -- > You are receiving this mail because: > You reported the bug.
(In reply to Dominique d'Humieres from comment #24) > > Le 11 mai 2017 à 09:06, gingold at adacore dot com <gcc-bugzilla@gcc.gnu.org> a écrit : > > Note that > > --with-stage1-ldflags=-static-libstdc++ > --with-boot-ldflags=-static-libstdc++ > > does not work if the install directory is empty: That's actually a different problem, what you're seeing there is that -static-libstdc++ is ignored on Darwin (dropped silently)... ... I.e. -static-libstdc++ only works on Darwin with a patch which I got fed up with pinging after 4 or so times. NOTE: AFAIR clang doesn't support that option anyway, so it would not be available at stage 1 where clang is the bootstrap compiler. However, the existing compiler build process points explicitly to the just-built libstdc++ convenience lib IIRC (the built tools are statically linked with the lib). So that info ought to be available to the Ada build (I'm pretty sure all the -B etc. is passed through).
Still present at revision r248811. Any chance to get this fixed?
> Still present at revision r248811. Any chance to get this fixed? Did you try what I suggested in comment #16 as a stopgap measure? No GNAT developer builds the mainline compiler on Darwin regularly so this may take a while to sort out otherwise.
(In reply to Iain Sandoe from comment #25) > NOTE: AFAIR clang doesn't support that option anyway, so it would not be > available at stage 1 where clang is the bootstrap compiler. clang doesn’t support Ada, so the stage 1 compiler has to be a (fairly recent, AFAICR) GCC.
> Did you try what I suggested in comment #16 as a stopgap measure? > No GNAT developer builds the mainline compiler on Darwin regularly > so this may take a while to sort out otherwise. I have wasted enough of my time with Ada. If its maintainers are unable to clean the mess caused by revision r247391, I could I? Closing as WONTFIX. Please do not reopen this PS and don't CC me for any further change in Ada.
s/I could I/how could I/
> --- Comment #29 from Dominique d'Humieres <dominiq at lps dot ens.fr> --- >> Did you try what I suggested in comment #16 as a stopgap measure? >> No GNAT developer builds the mainline compiler on Darwin regularly >> so this may take a while to sort out otherwise. > > I have wasted enough of my time with Ada. If its maintainers are unable to > clean the mess caused by revision r247391, I could I? > > Closing as WONTFIX. Please do not reopen this PS and don't CC me for any > further change in Ada. Then please keep the PR open, but set the `Ignore Bug Mail' flag so you won't see any further mails. The fact that you're no longer interested doesn't make the bug go away. When I tried the workaround, I got /var/gcc/regression/trunk/10.7-gcc/build/./gcc/xgcc -B/var/gcc/regression/trunk/10.7-gcc/build/./gcc/ -B/vol/gcc/x86_64-apple-darwin11.4.2/bin/ -B/vol/gcc/x86_64-apple-darwin11.4.2/lib/ -isystem /vol/gcc/x86_64-apple-darwin11.4.2/include -isystem /vol/gcc/x86_64-apple-darwin11.4.2/sys-include -c -g -O2 -fno-common -W -Wall -gnatpg -nostdinc g-exptty.adb -o g-exptty.o dyld: Symbol not found: __ZdaPvm Referenced from: /var/gcc/regression/trunk/10.7-gcc/build/./gcc/gnat1 Expected in: /usr/lib/libstdc++.6.dylib in /var/gcc/regression/trunk/10.7-gcc/build/./gcc/gnat1 xgcc: internal compiler error: Trace/BPT trap: 5 (program gnat1) Rainer
Oh, I forgot: does anyone have an explanation why i386-apple-darwin16.7.0 and i386-apple-darwin11.4.2 bootstraps *with* Ada still work fine while their x86_64 counterparts fail?
> I have wasted enough of my time with Ada. If its maintainers are unable to > clean the mess caused by revision r247391, I could I? Well, I only suggested to try the workaround, nothing more.
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #31) > When I tried the workaround, I got > > /var/gcc/regression/trunk/10.7-gcc/build/./gcc/xgcc > -B/var/gcc/regression/trunk/10.7-gcc/build/./gcc/ > -B/vol/gcc/x86_64-apple-darwin11.4.2/bin/ > -B/vol/gcc/x86_64-apple-darwin11.4.2/lib/ -isystem > /vol/gcc/x86_64-apple-darwin11.4.2/include -isystem > /vol/gcc/x86_64-apple-darwin11.4.2/sys-include -c -g -O2 -fno-common -W > -Wall -gnatpg -nostdinc g-exptty.adb -o g-exptty.o > dyld: Symbol not found: __ZdaPvm > Referenced from: /var/gcc/regression/trunk/10.7-gcc/build/./gcc/gnat1 > Expected in: /usr/lib/libstdc++.6.dylib > in /var/gcc/regression/trunk/10.7-gcc/build/./gcc/gnat1 > xgcc: internal compiler error: Trace/BPT trap: 5 (program gnat1) From previous experience building *with* shared libraries (because of pr61027 comment 4), when dyld loads the tools (code generators, gnat1, gnatbind) it looks for libstdc++ under $prefix, doesn't find it because it's not installed yet, tries the system libstdc++, fails because of that missing symbol. libgcc_s doesn’t appear to have the same issue. e.g. build/genmddeps ../../gcc-8-20170528/gcc/common.md ../../gcc-8-20170528/gcc/config/i386/i386.md > tmp-mddeps build/genmodes -h > tmp-modes.h dyld: Symbol not found: __ZdlPvm Referenced from: /Volumes/Miscellaneous/tmp/gcc-8-20170528-build/gcc/build/genmddeps (which was built for Mac OS X 10.12) Expected in: /usr/lib/libstdc++.6.dylib in /Volumes/Miscellaneous/tmp/gcc-8-20170528-build/gcc/build/genmddeps I temporarily install the just-built libraries under $prefix/lib and reconfigure, rebuild. Might be possible to work some DYLD_LIBRARY_PATH magic
> When I tried the workaround, I got > > /var/gcc/regression/trunk/10.7-gcc/build/./gcc/xgcc > -B/var/gcc/regression/trunk/10.7-gcc/build/./gcc/ > -B/vol/gcc/x86_64-apple-darwin11.4.2/bin/ > -B/vol/gcc/x86_64-apple-darwin11.4.2/lib/ -isystem > /vol/gcc/x86_64-apple-darwin11.4.2/include -isystem > /vol/gcc/x86_64-apple-darwin11.4.2/sys-include -c -g -O2 -fno-common -W > -Wall -gnatpg -nostdinc g-exptty.adb -o g-exptty.o > dyld: Symbol not found: __ZdaPvm > Referenced from: /var/gcc/regression/trunk/10.7-gcc/build/./gcc/gnat1 > Expected in: /usr/lib/libstdc++.6.dylib > in /var/gcc/regression/trunk/10.7-gcc/build/./gcc/gnat1 > xgcc: internal compiler error: Trace/BPT trap: 5 (program gnat1) The workaround is to filter out -static-libgcc in configure.ac on Darwin but to leave -static-libstdc++, so why is it still looking for the shared libstdc++?
(In reply to Eric Botcazou from comment #35) > The workaround is to filter out -static-libgcc in configure.ac on Darwin but > to leave -static-libstdc++, so why is it still looking for the shared > libstdc++? Because (as in comment 25) g++ linking on Darwin silently ignores -static-libstdc++ (if it sees -shared-libgcc). I've verified this with a C++ "hello world". This PR is labelled 'target', is that right? I’ve worked out a patch and bootstrapped (see attachment). The patch is against the gcc-8-20170558 snapshot, would that be OK? One thing I’m not sure of is what versions of Darwin this applies to. I’ve tested for *-apple-darwin*.
Created attachment 41474 [details] Patch to top-level configure.ac, configure
> I’ve worked out a patch and bootstrapped (see attachment). The patch is > against the gcc-8-20170558 snapshot, would that be OK? I'm no Darwin specialist so I cannot really comment, but my understanding is that it cannot make things worse... Please post it on gcc-patches@ if you don't mind. In any case, thanks for stepping in here. > One thing I’m not sure of is what versions of Darwin this applies to. I’ve > tested for *-apple-darwin*. The Darwin maintainers will probably enlighten once they see the patch.
Created attachment 41520 [details] Patch (2) to top-level configure.ac, configure The notes on -shared-libgcc at https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html say However, if a library or main executable is supposed to throw or catch exceptions, you must link it using the G++ driver, as appropriate for the languages used in the program, or using the option -shared-libgcc, such that it is linked with the shared libgcc. This seems not to be true for Linux (Debian Jessie) but is definitely true for Darwin. If, using GCC 7.1.0, we build with Ada.Text_IO; use Ada.Text_IO; procedure Raiser is begin begin raise Program_Error; exception when others => Put_Line ("caught it"); end; end Raiser; with $ gnatmake raiser -largs -static-libgcc -static-libstdc++ then $ ./raiser Illegal instruction: 4 The actual ld invocation was /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.12.0 -weak_reference_mismatches non-weak -o raiser -L./ -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/adalib/ -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0 -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/../../.. b~raiser.o ./raiser.o -v /opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/adalib/libgnat.a -no_compact_unwind -lgcc_eh -lgcc -lSystem This PR was raised because of a mishandled exception raised by Rtsfind.Load_Fail while processing g-exptty.adb. g-exptty.adb had been updated on 2017-04-25 (but so had a lot of other parts of GNAT). Since a lot of other compilations had been performed successfully by this point, one may assume that this was the first that actually caused an exception. Comment 14 works because --with-boot-ldflags=-static-libstdc++ means that the default boot-ldflags (-static-libgcc -static-libstdc++) is overridden, so that libgcc defaults to being shared (and -static-libstdc++ is ignored, as per comment 25, resulting in the stage 2 problems in comment 5, comment 24). Following the suggestion on comment 22 (put -lSystem before -lgcc), I've tried gcc-8-20170528 with --with-stage1-ldflags='-lSystem -static-libgcc -static-libstdc++' --with-boot-ldflags='-lSystem -static-libgcc -static-libstdc++' AND IT WORKS!!!! (on macOS Sierra, Debian jessie). Changing the command line above to the equivalent $ gnatmake raiser -largs -lSystem -static-libgcc -static-libstdc++ results in the ld invocation /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.12.0 -weak_reference_mismatches non-weak -o raiser -L./ -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/adalib/ -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0 -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/../../.. b~raiser.o ./raiser.o -lSystem -v /opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/adalib/libgnat.a -no_compact_unwind -lgcc_eh -lgcc -lSystem and $ ./raiser caught it Updated patch posted here; working on gcc-patches@ submission. ======================================================================== I'd like to point out that even if gnat1 hadn't failed, building GNAT tools without shared libgcc results in failures as in PR61027; but they only affect users of the tools, not the bootstrap.
> --- Comment #39 from simon at pushface dot org --- [...] > Updated patch posted here; working on gcc-patches@ submission. Thanks for the analysis and the patch. I'll give it a whirl once PR bootstrap/81033 is resolved. One nit for actual submission: your current patch contains lots of unrelated changes, removing trailing whitespace. While that is fine in itself, please move it to a separate patch. Thanks. Rainer
Created attachment 41531 [details] Patch (3) to top-level configure.ac, configure (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #40) > > --- Comment #39 from simon at pushface dot org --- > [...] > > Updated patch posted here; working on gcc-patches@ submission. > > Thanks for the analysis and the patch. I'll give it a whirl once PR > bootstrap/81033 is resolved. > > One nit for actual submission: your current patch contains lots of > unrelated changes, removing trailing whitespace. While that is fine in > itself, please move it to a separate patch. Oops, sorry about that.
Just for the record: at r249012 (i.e. before the patches causing PR bootstrap/81033), I managed to successfully bootstrap x86_64-apple-darwin16.6.0, x86_64-apple-darwin11.4.2, and i386-apple-darwin11.4.2. Thanks. Rainer
Created attachment 41651 [details] Patch to gcc/config/darwin.h Following up on a comment from Jeff Law on gcc-patches@, I replied as follows (it didn't appear on the archive, so I've re-sent) > I'm a bit confused here. Isn't -lSystem included in darwin's > LIB_SPEC in which case the right things ought to already be > happening, shouldn't it? The specs that involve -lSystem are *link_gcc_c_sequence: %:version-compare(>= 10.6 mmacosx-version-min= -no_compact_unwind) %{!static:%{!static-libgcc: %:version-compare(>= 10.6 mmacosx-version-min= -lSystem) } } %{fno-pic|fno-PIC|fno-pie|fno-PIE|fapple-kext|mkernel|static|mdynamic-no-pic: %:version-compare(>= 10.7 mmacosx-version-min= -no_pie) } %G %L *lib: %{!static:-lSystem} but I also see *libgcc: %{static-libgcc|static: -lgcc_eh -lgcc; .... which might be the root of the problem? In comment 39, I report that $ gnatmake raiser -largs -static-libgcc -static-libstdc++ resulted in the link command /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.12.0 -weak_reference_mismatches non-weak -o raiser -L./ -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/adalib/ -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0 -L/opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/../../.. b~raiser.o ./raiser.o -v /opt/gcc-7.1.0/lib/gcc/x86_64-apple-darwin15/7.1.0/adalib/libgnat.a -no_compact_unwind -lgcc_eh -lgcc -lSystem i.e. -lSystem is *after* -lgcc, so that its exception handling won't be invoked. I don't know what -lgcc_eh does, but my patch would be pretty much equivalent to changing the libgcc spec above to *libgcc: %{static-libgcc|static: -lSystem -lgcc_eh -lgcc; .... and if that would be OK it would obviously be much better. I've rebuilt gcc-8-20170528 with this, successfully; the last line of the raiser.adb link command above becomes -no_compact_unwind -lSystem -lgcc_eh -lgcc -lSystem and the exception is properly handled. Patch attached.
So coming back to this. Thanks for outlining the key specs. So link_gcc_c_sequence doesn't pull in -lSystem because of -static-libgcc, but it does appear (after -lgcc_eh -lgcc) because of of the %lib spec which only avoids -lSystem if -static was specified, but not -static-libgcc. Fixing the specs seems preferable to me over the original patch. It'd be ideal if we could get someone with Darwin expertise to chime in on your patch to REAL_LIBGCC_SPEC as a second opinion -- I'm just not qualified enough in any aspects of Darwin to give a final ACK here.
*** Bug 82141 has been marked as a duplicate of this bug. ***
I posted my darwin.h patch at https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00045.html on 1 September - hasn’t attracted any notice yet.
This PR is "fixed" by applying the patch at https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00045.html on top of revision r251529. However it does not fix pr82141. > I posted my darwin.h patch at > https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00045.html > on 1 September - hasn’t attracted any notice yet. May be PING for it.
(In reply to simon from comment #46) > I posted my darwin.h patch at > https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00045.html on 1 September - > hasn’t attracted any notice yet. Thanks for the patch Simon, and apologies that no-one has reviewed it yet. I am trying to catch up on the state of this (and other pending Darwin issues). As it is, the patch needs some more work, since the unwinder needs to come from different places in different versions of Darwin. As I read it, you've made the change unconditional which will most likely break earlier Darwin versions. Currently, I'm trying to reproduce the various issues, and will have some suggestions for amendment of the patch once I can get Ada to bootstrap. Once that's happening, I'll reply to the @patches post.
The patch at https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00045.html is still needed after revision r252914 (fix for pr81361).
(In reply to Dominique d'Humieres from comment #49) > The patch at https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00045.html is > still needed after revision r252914 (fix for pr81361). Yes, that's expected at present. a. there's evidently some more EH breakage caused by the reorder-and-partition (see 81733) b. the libgcc unwinder seems to have some issues even on systems that should support it c. we need to do some checking on the availability of the kernel call to fetch the FDEs and setup the specs accordingly. -static-libstdc++ is a workaround (actually, all it's really doing is overriding the -static-libgcc). IMO we need to get to the bottom of the various breakages, and preferably fix them properly - rather than applying a band-aid patch to place libSystem ahead of libgcc_eh.
(In reply to Rainer Orth from comment #10) > Interestingly, a i386-apple-darwin16 bootstrap *does* work fine. That's because the keymgr does work for m32 binaries. It's never kept track of images for x86_64 (from 10.6+, anyway) I'm not sure if / when last I ever tried a static linked libgcc on m64.
> Yes, that's expected at present. > a. there's evidently some more EH breakage caused by the > reorder-and-partition (see 81733) > b. the libgcc unwinder seems to have some issues even on systems that should > support it > c. we need to do some checking on the availability of the kernel call to > fetch the FDEs and setup the specs accordingly. IMO a. and b. are not top priority, we should first restore Ada bootstrap on recent Darwins with the system unwinder. > -static-libstdc++ is a workaround (actually, all it's really doing is > overriding the -static-libgcc). Yes, -static-libgcc is the problem on Darwin.
(In reply to Eric Botcazou from comment #52) > > Yes, that's expected at present. > > a. there's evidently some more EH breakage caused by the > > reorder-and-partition (see 81733) > > b. the libgcc unwinder seems to have some issues even on systems that should > > support it > > c. we need to do some checking on the availability of the kernel call to > > fetch the FDEs and setup the specs accordingly. > > IMO a. and b. are not top priority, we should first restore Ada bootstrap on > recent Darwins with the system unwinder. it would seem that the partitioning is still part of the issue (81733 isn't completely fixed by the patch for 81361). We just don't know what other ways it might manifest. > > -static-libstdc++ is a workaround (actually, all it's really doing is > > overriding the -static-libgcc). > > Yes, -static-libgcc is the problem on Darwin. So, we can hack around the problems with; 1) temporarily disable the partitioning 2) force libSystem ahead of libgcc_eh for Darwin >= 10 - this second one would ideally be for m64 only. will experiment with some specs fixes later.
Created attachment 42198 [details] workaround patch This is a workaround, to avoid Ada bootstrap breakage. what should happen: - for x86-64 (m64) Darwin we should get -lSystem -lgcc_eh -lgcc -lSystem (thus picking up the unwinder from libSystem=>libunwind. - for x86 (m32) we should get -lgcc_eh -lgcc -lSystem which links the unwinder from libgcc_eh (as before). So, the first case works around the unusable unwinder in m64 libgcc and the second case preserves the status quo for m32. you should be able to confirm this with some trivial code using the unwinder, linked -static-libgcc: (m32) $ DYLD_PRINT_LIBRARIES=1 DYLD_PRINT_BINDINGS=1 ./t 2>&1 |grep _Un <empty> (m64) $ DYLD_PRINT_LIBRARIES=1 DYLD_PRINT_BINDINGS=1 ./t 2>&1 |grep _Un dyld: lazy bind: t:0x1044D1080 = libunwind.dylib:__Unwind_RaiseException, *0x1044D1080 = 0x7FFF8F975918 dyld: lazy bind: t:0x1044D1068 = libunwind.dylib:__Unwind_GetLanguageSpecificData, *0x1044D1068 = 0x7FFF8F9763D0 dyld: lazy bind: t:0x1044D1070 = libunwind.dylib:__Unwind_GetRegionStart, *0x1044D1070 = 0x7FFF8F9763F3 dyld: lazy bind: t:0x1044D1060 = libunwind.dylib:__Unwind_GetIPInfo, *0x1044D1060 = 0x7FFF8F97A266 dyld: lazy bind: t:0x1044D1098 = libunwind.dylib:__Unwind_SetGR, *0x1044D1098 = 0x7FFF8F9765A0 dyld: lazy bind: t:0x1044D10A0 = libunwind.dylib:__Unwind_SetIP, *0x1044D10A0 = 0x7FFF8F976760 dyld: lazy bind: t:0x1044D1050 = libunwind.dylib:__Unwind_DeleteException, *0x1044D1050 = 0x7FFF8F9767F1 === I bootstrapped r252936 on x86-64 Darwin15.6 (10.11.6), it would be good if folks could check it out. Haven't tried an i386 bootstrap. === As per comment #20, we really need to rationalise our libgcc/crts to suit the range of use-cases. I've started rebasing the patches for this...
(In reply to Iain Sandoe from comment #54) > I bootstrapped r252936 on x86-64 Darwin15.6 (10.11.6), it would be good if > folks could check it out. bootstrapped r252935 on 10.11.6: === gnat Summary === # of expected passes 2604 # of unexpected failures 1 # of expected failures 24 # of unsupported tests 7 === acats Summary === # of expected passes 2320 # of unexpected failures 0
> --- Comment #55 from simon at pushface dot org --- > (In reply to Iain Sandoe from comment #54) > >> I bootstrapped r252936 on x86-64 Darwin15.6 (10.11.6), it would be good if >> folks could check it out. > > bootstrapped r252935 on 10.11.6: [...] Same here on x86_64-apple-darwin11.4.2 (all languages), where I replaced Simon's previous workaround with your patch. Now running an i386-apple-darwin11.4.2 bootstrap, which will take another day. Rainer
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #56) > > --- Comment #55 from simon at pushface dot org --- > > (In reply to Iain Sandoe from comment #54) > > > >> I bootstrapped r252936 on x86-64 Darwin15.6 (10.11.6), it would be good if > >> folks could check it out. > > > > bootstrapped r252935 on 10.11.6: > [...] > > Same here on x86_64-apple-darwin11.4.2 (all languages), where I replaced > Simon's previous workaround with your patch. > > Now running an i386-apple-darwin11.4.2 bootstrap, which will take > another day. thanks all! Dominique reported OK on Darwin16 and Darwin10 on irc, so I think if the i386 bootstrap is successful - this should be good to go (for now)
> --- Comment #57 from Iain Sandoe <iains at gcc dot gnu.org> --- [...] >> Now running an i386-apple-darwin11.4.2 bootstrap, which will take >> another day. > Dominique reported OK on Darwin16 and Darwin10 on irc, so I think if the i386 > bootstrap is successful - this should be good to go (for now) It just did complete successfully, so the patch is good to go, I believe. Thanks. Rainer
Author: iains Date: Mon Sep 25 08:47:41 2017 New Revision: 253137 URL: https://gcc.gnu.org/viewcvs?rev=253137&root=gcc&view=rev Log: [Patch, Darwin] Fix PR80556 by linking the system unwinder ahead of libgcc_eh. PR target/80556 * config/i386/darwin.h (REAL_LIB_SPEC): New; put libSystem ahead of libgcc_eh for m64. * config/i386/darwin64.h: Likewise. /* WORKAROUND pr80556: For x86_64 Darwin10 and later, the unwinder is in libunwind (redirected from libSystem). This doesn't use the keymgr (see keymgr.c) and therefore the calls that libgcc makes to obtain the KEYMGR_GCC3_DW2_OBJ_LIST are not updated to include new images, and might not even be valid for a single image. Therefore, for 64b exes at least, we must use the libunwind implementation, even when static-libgcc is specified. We put libSystem first so that unwinder symbols are satisfied from there. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/darwin.h trunk/gcc/config/i386/darwin64.h
so fixed
Nice work, thanks! But I'm sure the next Darwin crisis is already looming. ;-)
Author: iains Date: Sun May 19 16:03:17 2019 New Revision: 271381 URL: https://gcc.gnu.org/viewcvs?rev=271381&root=gcc&view=rev Log: darwin - fix PR86215 by backporting 80556. The backport had been missed. 2019-01-03 Iain Sandoe <iain@sandoe.co.uk> PR target/86215 Backport from mainline 2017-09-25 Iain Sandoe <iain@codesourcery.com> PR target/80556 * config/i386/darwin.h (REAL_LIB_SPEC): New; put libSystem ahead of libgcc_eh for m64. * config/i386/darwin64.h: Likewise. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/i386/darwin.h branches/gcc-7-branch/gcc/config/i386/darwin64.h
I'm reopening this because (a) the fix applied was a work-around and it's time to fix the Darwin unwinder hassles properly (b) it regresses gcc.dg/torture/fp-int-convert-timode-3.c to place libSystem() in front of libgcc.
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>: https://gcc.gnu.org/g:d4943ce939d9654932624b9ece24c3a474ae4157 commit r12-5418-gd4943ce939d9654932624b9ece24c3a474ae4157 Author: Iain Sandoe <iain@sandoe.co.uk> Date: Mon Sep 20 18:41:56 2021 +0100 Darwin: Rework handling for unwinder code in libgcc_s and specs [PR80556]. This addresses a long-standing problem where a work-around for an unwinder issue (also a regression) regresses other functionality. The patch replaces several work-arounds with a fix for PR80556 and a work-around for PR88590. * The fix for PR80556 requires a bump to the SO name for libgcc_s, since we need to remove the unwinder symbols from it. This would trigger PR88590 hence the work-around for that. * We weaken the symbols for emulated TLS support so that it is possible for a DSO linked with static-libgcc to interoperate with a DSO linked with libgcc_s. Likewise main exes. * We remove all the gcc-4.2.1 era stubs machinery and workarounds. * libgcc is always now linked ahead of libc, which avoids fails where the libc (libSystem) builtins implementations are not up to date. * The unwinder now always comes from the system - for Darwin9 from /usr/lib/libgcc_s.1.dylib - for Darwin10 from /usr/lib/libSystem.dylib - for Darwin11+ from /usr/lib/system/libunwind.dylib. We still insert a shim on Darwin10 to fix an omitted unwind function, but the underlying unwinder remains the system one. * The work-around for PR88590 has two parts (1) we always link libgcc from its convenience lib on affected system versions (avoiding the need to find the DSO path); (2) we add and export the emutls functions from DSOs - this makes a relatively small (20k) addition to a DSO. These can be backed out when a proper fix for PR88590 is committed. For distributions that wish to install a libgcc_s.1.dylib to satisfy linkage from exes that linked against the stubs can use a reexported libgcc_s.1.1 (since that contains all the symbols that were previously exported via the stubs). Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> gcc/ChangeLog: PR target/80556 * config/darwin-driver.c (darwin_driver_init): Handle exported symbols and symbol lists (suppress automatic export of the TLS symbols). * config/darwin.c (darwin_rename_builtins): Remove workaround. * config/darwin.h (LINK_GCC_C_SEQUENCE_SPEC): Likewise. (REAL_LIBGCC_SPEC): Handle revised library uses. * config/darwin.opt (nodefaultexport): New. * config/i386/darwin.h (PR80556_WORKAROUND): Remove. * config/i386/darwin32-biarch.h (PR80556_WORKAROUND): Likewise. * config/i386/darwin64-biarch.h (PR80556_WORKAROUND): Likewise. libgcc/ChangeLog: * config.host: Add weak emutls crt to the extra_parts. * config/i386/darwin-lib.h (DECLARE_LIBRARY_RENAMES): Remove workaround. * config/libgcc-libsystem.ver: Add exclude list for the system- provided unwinder. * config/t-slibgcc-darwin: Bump SO version, remove stubs code. * config/i386/libgcc-darwin.10.4.ver: Removed. * config/i386/libgcc-darwin.10.5.ver: Removed. * config/rs6000/libgcc-darwin.10.4.ver: Removed. * config/rs6000/libgcc-darwin.10.5.ver: Removed. * config/t-darwin-noeh: New file. gcc/testsuite/ChangeLog: * gcc.dg/torture/fp-int-convert-timode-3.c: Remove XFAIL. * gcc.dg/torture/fp-int-convert-timode-4.c: Likewise.
The releases/gcc-11 branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>: https://gcc.gnu.org/g:94c9c6acdc14de186abe4ea59c54920fbfb60beb commit r11-9878-g94c9c6acdc14de186abe4ea59c54920fbfb60beb Author: Iain Sandoe <iain@sandoe.co.uk> Date: Sat Sep 18 23:38:53 2021 +0100 Darwin: Rework handling for unwinder code in libgcc_s and specs [PR80556]. This addresses a long-standing problem where a work-around for an unwinder issue (also a regression) regresses other functionality. The patch replaces several work-arounds with a fix for PR80556 and a work-around for PR88590. * The fix for PR80556 requires a bump to the SO name for libgcc_s, since we need to remove the unwinder symbols from it. This would trigger PR88590 hence the work-around for that. * We weaken the symbols for emulated TLS support so that it is possible for a DSO linked with static-libgcc to interoperate with a DSO linked with libgcc_s. Likewise main exes. * We remove all the gcc-4.2.1 era stubs machinery and workarounds. * libgcc is always now linked ahead of libc, which avoids fails where the libc (libSystem) builtins implementations are not up to date. * The unwinder now always comes from the system - for Darwin9 from /usr/lib/libgcc_s.1.dylib - for Darwin10 from /usr/lib/libSystem.dylib - for Darwin11+ from /usr/lib/system/libunwind.dylib. We still insert a shim on Darwin10 to fix an omitted unwind function, but the underlying unwinder remains the system one. * The work-around for PR88590 has two parts (1) we always link libgcc from its convenience lib on affected system versions (avoiding the need to find the DSO path); (2) we add and export the emutls functions from DSOs - this makes a relatively small (20k) addition to a DSO. These can be backed out when a proper fix for PR88590 is committed. For distributions that wish to install a libgcc_s.1.dylib to satisfy linkage from exes that linked against the stubs can use a reexported libgcc_s.1.1 (since that contains all the symbols that were previously exported via the stubs). The replacement libgcc_s.1 forwards the symbols from the new SO. In order to support DYLD_LIBRARY_PATH on systems (where it works) we forward the libSystem unwinder symbols from 10.7+ and a compiler-local version of the libgcc unwinder on earlier. For macOS 10.4 to 10.6 this is 'bug-compatible' with existing uses. For 10.7+ the behaviour will now actually be correct. Backported from commits d4943ce939d9654932624b9ece24c3a474ae4157, 7add7f7bb3d35726a0c45322ffdbbab2bbf6a348, b504917e43b9a559c9ac779e08784ad412125f2e, 32731fa5b0abf092029b8e2be64319b978bda514, 574c09da48a5a0ff4c32dd4577eaf65bac8c94a0 and c18ddb05b0391a397f8882fc6a12a1bab7e0df52 Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> gcc/ChangeLog: PR target/80556 * config/darwin-driver.c (darwin_driver_init): Handle exported symbols and symbol lists (suppress automatic export of the TLS symbols). * config/darwin.c (darwin_rename_builtins): Remove workaround. * config/darwin.h (LINK_GCC_C_SEQUENCE_SPEC): Likewise. (REAL_LIBGCC_SPEC): Handle revised library uses. * config/darwin.opt (nodefaultexport): New. * config/i386/darwin.h (PR80556_WORKAROUND): Remove. * config/i386/darwin32-biarch.h (PR80556_WORKAROUND): Likewise. * config/i386/darwin64-biarch.h (PR80556_WORKAROUND): Likewise. libgcc/ChangeLog: * config.host: Add weak emutls crt to the extra_parts. (*-*-darwin*): Add logic to build a shared unwinder library for Darwin8-10. Add shim declaration header to powerpc*-darwin builds. * config/i386/darwin-lib.h (DECLARE_LIBRARY_RENAMES): Remove workaround. * config/libgcc-libsystem.ver: Add exclude list for the system- provided unwinder. * config/t-slibgcc-darwin: Bump SO version, remove stubs code. Build a legacy libgcc_s.1 and the supporting pieces (all FAT libs). * config/t-darwin-ehs: Add dependencies to the shared unwinder objects. Add dependency on unwind.h. * config/t-darwin: Reorganise the EH fragments to place them for inclusion in a shared EH lib. Add libgcc_tm.h to the dependencies for darwin10-unwind-find-enc-func. * config/i386/libgcc-darwin.10.4.ver: Removed. * config/i386/libgcc-darwin.10.5.ver: Removed. * config/rs6000/libgcc-darwin.10.4.ver: Removed. * config/rs6000/libgcc-darwin.10.5.ver: Removed. * config/i386/t-darwin: Build legacy libgcc_s.1. * config/rs6000/t-darwin: Likewise. * config/rs6000/t-darwin-ehs: Remove dependency on the powerpc end file. Add darwin-fallback.o. gcc/testsuite/ChangeLog: * gcc.dg/torture/fp-int-convert-timode-3.c: Remove XFAIL. * gcc.dg/torture/fp-int-convert-timode-4.c: Likewise.
The releases/gcc-10 branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>: https://gcc.gnu.org/g:bf41b26f5891c6ce3b1ffe41d3736a566db02390 commit r10-10795-gbf41b26f5891c6ce3b1ffe41d3736a566db02390 Author: Iain Sandoe <iain@sandoe.co.uk> Date: Sat Sep 18 23:38:53 2021 +0100 Darwin: Rework handling for unwinder code in libgcc_s and specs [PR80556]. This addresses a long-standing problem where a work-around for an unwinder issue (also a regression) regresses other functionality. The patch replaces several work-arounds with a fix for PR80556 and a work-around for PR88590. * The fix for PR80556 requires a bump to the SO name for libgcc_s, since we need to remove the unwinder symbols from it. This would trigger PR88590 hence the work-around for that. * We weaken the symbols for emulated TLS support so that it is possible for a DSO linked with static-libgcc to interoperate with a DSO linked with libgcc_s. Likewise main exes. * We remove all the gcc-4.2.1 era stubs machinery and workarounds. * libgcc is always now linked ahead of libc, which avoids fails where the libc (libSystem) builtins implementations are not up to date. * The unwinder now always comes from the system - for Darwin9 from /usr/lib/libgcc_s.1.dylib - for Darwin10 from /usr/lib/libSystem.dylib - for Darwin11+ from /usr/lib/system/libunwind.dylib. We still insert a shim on Darwin10 to fix an omitted unwind function, but the underlying unwinder remains the system one. * The work-around for PR88590 has two parts (1) we always link libgcc from its convenience lib on affected system versions (avoiding the need to find the DSO path); (2) we add and export the emutls functions from DSOs - this makes a relatively small (20k) addition to a DSO. These can be backed out when a proper fix for PR88590 is committed. For distributions that wish to install a libgcc_s.1.dylib to satisfy linkage from exes that linked against the stubs can use a reexported libgcc_s.1.1 (since that contains all the symbols that were previously exported via the stubs). The replacement libgcc_s.1 forwards the symbols from the new SO. In order to support DYLD_LIBRARY_PATH on systems (where it works) we forward the libSystem unwinder symbols from 10.7+ and a compiler-local version of the libgcc unwinder on earlier. For macOS 10.4 to 10.6 this is 'bug-compatible' with existing uses. For 10.7+ the behaviour will now actually be correct. Backported from commits d4943ce939d9654932624b9ece24c3a474ae4157, 7add7f7bb3d35726a0c45322ffdbbab2bbf6a348, b504917e43b9a559c9ac779e08784ad412125f2e, 32731fa5b0abf092029b8e2be64319b978bda514, 574c09da48a5a0ff4c32dd4577eaf65bac8c94a0 and c18ddb05b0391a397f8882fc6a12a1bab7e0df52 Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> gcc/ChangeLog: PR target/80556 * config/darwin-driver.c (darwin_driver_init): Handle exported symbols and symbol lists (suppress automatic export of the TLS symbols). * config/darwin.c (darwin_rename_builtins): Remove workaround. * config/darwin.h (LINK_GCC_C_SEQUENCE_SPEC): Likewise. (REAL_LIBGCC_SPEC): Handle revised library uses. * config/darwin.opt (nodefaultexport): New. * config/i386/darwin.h (PR80556_WORKAROUND): Remove. * config/i386/darwin32-biarch.h (PR80556_WORKAROUND): Likewise. * config/i386/darwin64-biarch.h (PR80556_WORKAROUND): Likewise. libgcc/ChangeLog: * config.host: Add weak emutls crt to the extra_parts. (*-*-darwin*): Add logic to build a shared unwinder library for Darwin8-10. Add shim declaration header to powerpc*-darwin builds. * config/i386/darwin-lib.h (DECLARE_LIBRARY_RENAMES): Remove workaround. * config/libgcc-libsystem.ver: Add exclude list for the system- provided unwinder. * config/t-slibgcc-darwin: Bump SO version, remove stubs code. Build a legacy libgcc_s.1 and the supporting pieces (all FAT libs). * config/t-darwin-ehs: Add dependencies to the shared unwinder objects. Add dependency on unwind.h. * config/t-darwin: Reorganise the EH fragments to place them for inclusion in a shared EH lib. Add libgcc_tm.h to the dependencies for darwin10-unwind-find-enc-func. * config/i386/libgcc-darwin.10.4.ver: Removed. * config/i386/libgcc-darwin.10.5.ver: Removed. * config/rs6000/libgcc-darwin.10.4.ver: Removed. * config/rs6000/libgcc-darwin.10.5.ver: Removed. * config/i386/t-darwin: Build legacy libgcc_s.1. * config/rs6000/t-darwin: Likewise. * config/rs6000/t-darwin-ehs: Remove dependency on the powerpc end file. Add darwin-fallback.o. gcc/testsuite/ChangeLog: * gcc.dg/torture/fp-int-convert-timode-3.c: Remove XFAIL. * gcc.dg/torture/fp-int-convert-timode-4.c: Likewise.
so fixed on open branches, needed on at least 8.x / 9.x for vendor branches.