Bug 80556 - [8 Regression] bootstrap failure for Ada compiler
Summary: [8 Regression] bootstrap failure for Ada compiler
Status: REOPENED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 8.0
: P3 major
Target Milestone: 8.0
Assignee: Not yet assigned to anyone
URL: https://gcc.gnu.org/ml/gcc-patches/20...
Keywords:
Depends on:
Blocks:
 
Reported: 2017-04-28 12:01 UTC by Dominique d'Humieres
Modified: 2019-09-22 14:09 UTC (History)
8 users (show)

See Also:
Host: x86_64-apple-darwin16
Target: x86_64-apple-darwin16
Build: x86_64-apple-darwin16
Known to work:
Known to fail:
Last reconfirmed: 2017-04-28 00:00:00


Attachments
Patch to top-level configure.ac, configure (510 bytes, patch)
2017-06-05 12:59 UTC, simon
Details | Diff
Patch (2) to top-level configure.ac, configure (3.01 KB, patch)
2017-06-09 13:04 UTC, simon
Details | Diff
Patch (3) to top-level configure.ac, configure (510 bytes, patch)
2017-06-10 09:53 UTC, simon
Details | Diff
Patch to gcc/config/darwin.h (409 bytes, patch)
2017-06-29 17:14 UTC, simon
Details | Diff
workaround patch (831 bytes, patch)
2017-09-18 19:13 UTC, Iain Sandoe
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dominique d'Humieres 2017-04-28 12:01:30 UTC
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.
Comment 1 Dominique d'Humieres 2017-04-28 15:44:07 UTC
Not fixed at revision r247391.
Comment 2 Eric Botcazou 2017-04-29 08:51:32 UTC
Other native platforms seem fine, so please post a backtrace.
Comment 3 Dominique d'Humieres 2017-04-29 14:09:48 UTC
> 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
Comment 4 Eric Botcazou 2017-04-29 19:11:21 UTC
> 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.
Comment 5 Dominique d'Humieres 2017-05-01 10:43:13 UTC
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)
Comment 6 Tristan Gingold 2017-05-02 06:31:22 UTC
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

>
Comment 7 Eric Botcazou 2017-05-02 06:49:49 UTC
> 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?
Comment 8 Dominique d'Humieres 2017-05-02 13:10:32 UTC
> 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.
Comment 9 Tom de Vries 2017-05-05 13:19:19 UTC
PR80590 could be a non-darwin duplicate.
Comment 10 Rainer Orth 2017-05-06 12:29:06 UTC
Interestingly, a i386-apple-darwin16 bootstrap *does* work fine.
Comment 11 Dominique d'Humieres 2017-05-09 12:43:23 UTC
Any chance to see this PR fixed soon?
Comment 12 Tristan Gingold 2017-05-09 12:55:59 UTC
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 ?
Comment 13 Dominique d'Humieres 2017-05-09 13:14:14 UTC
> 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
Comment 14 Tristan Gingold 2017-05-09 13:17:13 UTC
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.
Comment 15 Dominique d'Humieres 2017-05-09 15:41:23 UTC
> 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.
Comment 16 Eric Botcazou 2017-05-10 06:43:03 UTC
> 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@?
Comment 17 Tristan Gingold 2017-05-10 07:26:50 UTC
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.
Comment 18 Dominique d'Humieres 2017-05-10 16:04:18 UTC
> 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?
Comment 19 Tristan Gingold 2017-05-11 07:06:41 UTC
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.
Comment 20 Iain Sandoe 2017-05-11 07:44:26 UTC
(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?
Comment 21 Tristan Gingold 2017-05-11 07:49:23 UTC
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++
Comment 22 Iain Sandoe 2017-05-11 08:11:54 UTC
(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).
Comment 23 Tristan Gingold 2017-05-11 08:20:28 UTC
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.
Comment 24 Dominique d'Humieres 2017-05-11 13:39:40 UTC
> 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.
Comment 25 Iain Sandoe 2017-05-11 13:51:41 UTC
(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).
Comment 26 Dominique d'Humieres 2017-06-02 08:12:27 UTC
Still present at revision r248811. Any chance to get this fixed?
Comment 27 Eric Botcazou 2017-06-02 08:32:59 UTC
> 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.
Comment 28 simon 2017-06-02 16:39:27 UTC
(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.
Comment 29 Dominique d'Humieres 2017-06-03 14:26:49 UTC
> 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.
Comment 30 Dominique d'Humieres 2017-06-03 14:28:10 UTC
s/I could I/how could I/
Comment 31 ro@CeBiTec.Uni-Bielefeld.DE 2017-06-03 14:52:49 UTC
> --- 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
Comment 32 ro@CeBiTec.Uni-Bielefeld.DE 2017-06-03 15:01:17 UTC
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?
Comment 33 Eric Botcazou 2017-06-03 21:15:37 UTC
> 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.
Comment 34 simon 2017-06-04 10:41:09 UTC
(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
Comment 35 Eric Botcazou 2017-06-05 06:19:22 UTC
> 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++?
Comment 36 simon 2017-06-05 12:57:42 UTC
(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*.
Comment 37 simon 2017-06-05 12:59:13 UTC
Created attachment 41474 [details]
Patch to top-level configure.ac, configure
Comment 38 Eric Botcazou 2017-06-05 22:07:52 UTC
> 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.
Comment 39 simon 2017-06-09 13:04:53 UTC
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 40 ro@CeBiTec.Uni-Bielefeld.DE 2017-06-09 13:16:35 UTC
> --- 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
Comment 41 simon 2017-06-10 09:53:28 UTC
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.
Comment 42 ro@CeBiTec.Uni-Bielefeld.DE 2017-06-12 08:15:49 UTC
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
Comment 43 simon 2017-06-29 17:14:14 UTC
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.
Comment 44 Jeffrey A. Law 2017-08-28 14:55:56 UTC
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.
Comment 45 Eric Botcazou 2017-09-08 08:36:47 UTC
*** Bug 82141 has been marked as a duplicate of this bug. ***
Comment 46 simon 2017-09-08 12:31:55 UTC
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.
Comment 47 Dominique d'Humieres 2017-09-08 21:57:23 UTC
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.
Comment 48 Iain Sandoe 2017-09-11 06:44:21 UTC
(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.
Comment 49 Dominique d'Humieres 2017-09-18 12:18:45 UTC
The patch at https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00045.html is still needed after revision r252914 (fix for pr81361).
Comment 50 Iain Sandoe 2017-09-18 12:36:35 UTC
(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.
Comment 51 Iain Sandoe 2017-09-18 14:29:29 UTC
(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.
Comment 52 Eric Botcazou 2017-09-18 16:00:56 UTC
> 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.
Comment 53 Iain Sandoe 2017-09-18 16:42:56 UTC
(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.
Comment 54 Iain Sandoe 2017-09-18 19:13:27 UTC
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...
Comment 55 simon 2017-09-21 16:23:32 UTC
(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 56 ro@CeBiTec.Uni-Bielefeld.DE 2017-09-21 16:27:11 UTC
> --- 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
Comment 57 Iain Sandoe 2017-09-21 16:43:34 UTC
(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 58 ro@CeBiTec.Uni-Bielefeld.DE 2017-09-22 21:59:42 UTC
> --- 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
Comment 59 Iain Sandoe 2017-09-25 08:48:16 UTC
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
Comment 60 Iain Sandoe 2017-09-25 08:57:27 UTC
so fixed
Comment 61 Eric Botcazou 2017-09-25 09:54:01 UTC
Nice work, thanks!  But I'm sure the next Darwin crisis is already looming. ;-)
Comment 62 Iain Sandoe 2019-05-19 16:03:48 UTC
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
Comment 63 Iain Sandoe 2019-05-19 16:08:10 UTC
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.