[Bug target/48097] New: new Throw_2 failures in libjava under Xcode 4.0

[Bug target/48097] New: new Throw_2 failures in libjava under Xcode 4.0

[howarth at nitro dot med.uc.edu]

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

           Summary: new Throw_2 failures in libjava under Xcode 4.0
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: howarth@nitro.med.uc.edu


The libjava testsuite exhibits four new execution failures for Throw_2 when
Xcode 4.0 is installed...


FAIL: Throw_2 execution - source compiled test
FAIL: Throw_2 -findirect-dispatch execution - source compiled test
FAIL: Throw_2 -O3 execution - source compiled test
FAIL: Throw_2 -O3 -findirect-dispatch execution - source compiled test

These are not present when Xcode 3.2.5 is used for cctools. These fail as
follows...

[MacPro:x86_64-apple-darwin10.7.0/libjava/testsuite] root#
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/libjava/testsuite/../libtool
--silent --tag=GCJ --mode=link
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/gcj
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/libjava/
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/
-B/sw/lib/gcc4.6/x86_64-apple-darwin10.7.0/bin/
-B/sw/lib/gcc4.6/x86_64-apple-darwin10.7.0/lib/ -isystem
/sw/lib/gcc4.6/x86_64-apple-darwin10.7.0/include -isystem
/sw/lib/gcc4.6/x86_64-apple-darwin10.7.0/sys-include    --encoding=UTF-8
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/libjava/testsuite/../
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20110311/libjava/testsuite/libjava.lang/Throw_2.jar
 -w  -bind_at_load -multiply_defined suppress -Wl,-allow_stack_execute
--main=Throw_2 -g 
-L/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/./libjava/.libs
-lm   -m64 -o
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/libjava/testsuite/Throw_2.exe
[MacPro:x86_64-apple-darwin10.7.0/libjava/testsuite] root# ./Throw_2.exe
1
Abort

It is interesting that the gdb from Xcode 4.0 doesn't like this executable...


[MacPro:x86_64-apple-darwin10.7.0/libjava/testsuite] root# gdb ./Throw_2.exe
GNU gdb 6.3.50-20050815 (Apple version gdb-1518) (Sat Feb 12 02:52:12 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared
libraries ....
warning: Could not find object file
"/sw/src/fink.build/libiconv-1.12-4/libiconv-1.12/lib/.libs/iconv.o" - no debug
information available for "./iconv.c".


warning: Could not find object file
"/sw/src/fink.build/libiconv-1.12-4/libiconv-1.12/lib/.libs/localcharset.o" -
no debug information available for "./../libcharset/lib/localcharset.c".


warning: Could not find object file
"/sw/src/fink.build/libiconv-1.12-4/libiconv-1.12/lib/.libs/relocatable.o" - no
debug information available for "./relocatable.c".

.. done

gdb stack crawl at point of internal error:
0   gdb-i386-apple-darwin               0x000000010010a10a internal_vproblem +
308
1   gdb-i386-apple-darwin               0x000000010010a2e4 internal_verror + 27
2   gdb-i386-apple-darwin               0x000000010010a382 align_down + 0
3   gdb-i386-apple-darwin               0x00000001000b4426
find_partial_die_in_comp_unit + 88
4   gdb-i386-apple-darwin               0x00000001000bff8b find_partial_die +
628
5   gdb-i386-apple-darwin               0x00000001000bffd8 fixup_partial_die +
55
6   gdb-i386-apple-darwin               0x00000001000c06cd scan_partial_symbols
+ 58
7   gdb-i386-apple-darwin               0x00000001000c15a9
dwarf2_build_psymtabs + 3006
8   gdb-i386-apple-darwin               0x000000010014e1e0 macho_symfile_read +
299
9   gdb-i386-apple-darwin               0x000000010004fe18 syms_from_objfile +
1403
10  gdb-i386-apple-darwin               0x00000001000508bb
symbol_file_add_with_addrs_or_offsets_using_objfile + 780
11  gdb-i386-apple-darwin               0x0000000100050872
symbol_file_add_with_addrs_or_offsets_using_objfile + 707
12  gdb-i386-apple-darwin               0x0000000100050b69
symbol_file_add_name_with_addrs_or_offsets + 119
13  gdb-i386-apple-darwin               0x0000000100051031
symbol_file_add_main_1 + 207
14  gdb-i386-apple-darwin               0x0000000100073333 catch_command_errors
+ 65
/SourceCache/gdb/gdb-1518/src/gdb/dwarf2read.c:8388: internal-error: could not
find partial DIE in cache

A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n

(gdb) r
Starting program:
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/libjava/testsuite/Throw_2.exe 
Reading symbols for shared libraries . done
Reading symbols for shared libraries ...gdb stack crawl at point of internal
error:
0   gdb-i386-apple-darwin               0x000000010010a10a internal_vproblem +
308
1   gdb-i386-apple-darwin               0x000000010010a2e4 internal_verror + 27
2   gdb-i386-apple-darwin               0x000000010010a382 align_down + 0
3   gdb-i386-apple-darwin               0x00000001000b4426
find_partial_die_in_comp_unit + 88
4   gdb-i386-apple-darwin               0x00000001000bff8b find_partial_die +
628
5   gdb-i386-apple-darwin               0x00000001000bffd8 fixup_partial_die +
55
6   gdb-i386-apple-darwin               0x00000001000c06cd scan_partial_symbols
+ 58
7   gdb-i386-apple-darwin               0x00000001000c15a9
dwarf2_build_psymtabs + 3006
8   gdb-i386-apple-darwin               0x000000010014e1e0 macho_symfile_read +
299
9   gdb-i386-apple-darwin               0x000000010004fe18 syms_from_objfile +
1403
10  gdb-i386-apple-darwin               0x00000001000508bb
symbol_file_add_with_addrs_or_offsets_using_objfile + 780
11  gdb-i386-apple-darwin               0x0000000100050872
symbol_file_add_with_addrs_or_offsets_using_objfile + 707
12  gdb-i386-apple-darwin               0x0000000100051240
symbol_file_add_bfd_helper + 84
13  gdb-i386-apple-darwin               0x00000001000733b6 catch_errors + 70
14  gdb-i386-apple-darwin               0x000000010004d59a
symbol_file_add_bfd_safe + 187
/SourceCache/gdb/gdb-1518/src/gdb/dwarf2read.c:8388: internal-error: could not
find partial DIE in cache

A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n
.warning: Could not find object file
"/sw/src/fink.build/libiconv-1.12-4/libiconv-1.12/lib/.libs/iconv.o" - no debug
information available for "./iconv.c".

warning: Could not find object file
"/sw/src/fink.build/libiconv-1.12-4/libiconv-1.12/lib/.libs/localcharset.o" -
no debug information available for "./../libcharset/lib/localcharset.c".

warning: Could not find object file
"/sw/src/fink.build/libiconv-1.12-4/libiconv-1.12/lib/.libs/relocatable.o" - no
debug information available for "./relocatable.c".

... done
1

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000014
_ZN4java4lang6String6lengthEJiv (this=0x0) at String.java:451
451        return count;
(gdb) bt
#0  _ZN4java4lang6String6lengthEJiv (this=0x0) at String.java:451
#1  0x0000000100072ca9 in java::lang::VMDouble::parseDouble (str=0x0) at
../../../gcc-4.6-20110311/libjava/java/lang/natVMDouble.cc:165
#2  0x00000001004391ba in _ZN4java4lang6Double11parseDoubleEJdPNS0_6StringE
(str=0x0) at Double.java:348
#3  0x000000010006695e in gnu::java::lang::MainThread::call_main
(this=0x1000021f8) at
../../../gcc-4.6-20110311/libjava/gnu/java/lang/natMainThread.cc:54
Previous frame inner to this frame (gdb could not unwind past this frame)
(gdb)

[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0

[howarth at nitro dot med.uc.edu]

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

--- Comment #1 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-03-12 21:26:32 UTC ---
Using built-in specs.
COLLECT_GCC=gcc-4
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.7.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.7.0
Configured with: ../gcc-4.6-20110311/configure --prefix=/sw
--prefix=/sw/lib/gcc4.6 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.6/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-4.6 --enable-checking=yes --enable-cloog-backend=isl
Thread model: posix
gcc version 4.6.0 20110312 (experimental) (GCC)

[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0

[howarth at nitro dot med.uc.edu]

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

--- Comment #2 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-03-12 21:31:36 UTC ---
The same executable examined with Xcode 4.0's lldb shows...


[MacPro:x86_64-apple-darwin10.7.0/libjava/testsuite] howarth%
/Developer/usr/bin/lldb ./Throw_2.exe
Current executable set to './Throw_2.exe' (x86_64).
(lldb) r
Process 36422 launched:
'/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/libjava/testsuite/Throw_2.exe'
(x86_64)
(lldb) 1
(lldb) Process 36422 stopped
1 of 2 threads stopped with reasons:
* thread #1: tid = 0x2d03, 0x000000010043aa70 libgcj.12.dylib`int
java::lang::String::length() at String.java:451, stop reason = EXC_BAD_ACCESS
(code=1, address=0x14)
 448          */
 449         public int length()
 450         {
 451 ->        return count;
 452         }
 453       
 454         /**
(lldb) bt
thread #1: tid = 0x2d03, stop reason = EXC_BAD_ACCESS (code=1, address=0x14)
  frame #0: 0x000000010043aa70 libgcj.12.dylib`int java::lang::String::length()
at String.java:451
  frame #1: 0x0000000100072ca9 libgcj.12.dylib`double
java::lang::VMDouble::parseDouble(java::lang::String*) + 25 at
natVMDouble.cc:165
  frame #2: 0x00000001004391ba libgcj.12.dylib`double
java::lang::Double::parseDouble(java::lang::String*) + 26 at Double.java:348
  frame #3: 0x0000000100001adc Throw_2.exe`void
Throw_2::main(JArray<java::lang::String*>*) + 474 at Throw_2.java:47
  frame #4: 0x000000010006695e libgcj.12.dylib`void
gnu::java::lang::MainThread::call_main() + 206 at natMainThread.cc:54
  frame #5: 0x00000001000d1e44 libgcj.12.dylib`void
gnu::java::lang::MainThread::run() + 68 at MainThread.java:106
  frame #6: 0x000000010007785a
libgcj.12.dylib`_Jv_ThreadRun(java::lang::Thread*) + 42 at natThread.cc:335
  frame #7: 0x000000010002b322 libgcj.12.dylib`_Jv_RunMain(_Jv_VMInitArgs*,
java::lang::Class*, char const*, int, char const**, bool) + 306 at
prims.cc:1789
  frame #8: 0x000000010002b51a libgcj.12.dylib`_Jv_RunMain(java::lang::Class*,
char const*, int, char const**, bool) + 26 at prims.cc:1814
  frame #9: 0x000000010002b553 libgcj.12.dylib`JvRunMain + 19 at prims.cc:1820
  frame #10: 0x000000010000189f Throw_2.exe`main + 61 at ccP0miy8.i:11
  frame #11: 0x0000000100001840 Throw_2.exe`start + 52
(lldb)

[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0

[howarth at nitro dot med.uc.edu]

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

--- Comment #3 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-03-17 20:12:35 UTC ---
Opened radar Problem ID: 9149679, Xcode 4.0 regresses Throw_2.exe libjava
testcase. I wonder if this might just be a new permutation of the existing eh
epilogue issues on darwin.

[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0

[howarth at nitro dot med.uc.edu]

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

--- Comment #4 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-03-18 00:45:08 UTC ---
The darwin linker developer says....
----------------------------------------------------------------------------
This is not a tools bug.  It worked by luck with Xcode3 tools.  The is a
runtime bug in the uwinder.

The Throw2.exe does not matter.  All that matters is the libgcj.12.dylib
binary.  The test installs a signal handler and which turns the signal into a
C++ exception and throws it. This means it has to unwind through a sigtramp.
This generally works, but in this case the bus error happens on the first
instruction in a function (java::lang::String::length()).   When the unwinder
walks the stack, it assumes each address on the stack is a return address,
which means it is the address *after* the CALL site, so you look for an FDE
from with an address that covers the byte before the address you are looking
for.

In the xcode3 built libgcj.12.dylib, there was a function right before
java::lang::String::length().  In the xcode4 case there are pad bytes before
that function and the pad bytes are not covered by the FDE.  So at runtime, the
unwinder cannot find an FDE for the start address of
java::lang::String::length, hence the abort.

[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-18 08:10:02 UTC ---
That's something that has been fixed in PR26208 by adding S modifier for signal
frames and introducing _Unwind_GetIPInfo.  So, if Apple unwinder has that
function, it is just a matter of making sure signal frames are marked and such
(or MD_FALLBACK_FRAME_STATE_FOR in the unwinder handles it).
If it doesn't have that entry point and you can't switch to a newer unwinder,
you are out of luck.

[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> 2011-03-18 08:32:39 UTC ---
(In reply to comment #5)
> That's something that has been fixed in PR26208 by adding S modifier for signal
> frames and introducing _Unwind_GetIPInfo.  So, if Apple unwinder has that
> function, it is just a matter of making sure signal frames are marked and such
> (or MD_FALLBACK_FRAME_STATE_FOR in the unwinder handles it).
> If it doesn't have that entry point and you can't switch to a newer unwinder,
> you are out of luck.

Dawin's (Darwin 8, 9) unwinder is essentially from gcc_s at the time the system
was released;
Darwin 10's unwinder does the same as Darwin 9.

we have _Unwind_GetIPInfo on systems >= Darwin 9.

[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-18 08:53:03 UTC ---
Looking at gcc-4.2, there is no darwin MD_FALLBACK_FRAME_STATE_FOR for i?86 and
for powerpc it doesn't call _Unwind_SetSignalFrame (xxx, 1) unlike e.g. linux
MD_FALLBACK_FRAME_STATE_FOR.  Apparently that state didn't change even in 4.7,
but if nothing uses the gcc unwinder, all that matters for darwin is whether
Apple unwinder gets fixed.

[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0

[howarth at nitro dot med.uc.edu]

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

--- Comment #8 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-03-18 17:28:19 UTC ---
The response to Comments 5 through 7 from the darwin linker developer is...
-------------------------------------------------------------------------
Unfortunately, the _sigtramp function in our libSystem.dylib does not have the
'S' letter in its augmentation string. I wrote a bug for that.  With that
fixed, I'll need to verify our unwinder the properly uses that 'S' flag to
change the boundary conditions when search for the applicable FDE.
-------------------------------------------------------------------------
So it appears that if this gets fixed, it will likely only be for darwin11.

[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0

[howarth at nitro dot med.uc.edu]

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

--- Comment #9 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-02-26 02:49:28 UTC ---
Interestingly I see these failures in the i386-unknown-freebsd10.0 test
results...

http://gcc.gnu.org/ml/gcc-testresults/2012-02/msg02475.html

as well as the x86_64-unknown-freebsd8.3 test results...

http://gcc.gnu.org/ml/gcc-testresults/2012-02/msg02479.html

[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-09-14
     Ever confirmed|0                           |1

--- Comment #10 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jack Howarth from comment #8)
> The response to Comments 5 through 7 from the darwin linker developer is...
> -------------------------------------------------------------------------
> Unfortunately, the _sigtramp function in our libSystem.dylib does not have
> the 'S' letter in its augmentation string. I wrote a bug for that.  With
> that fixed, I'll need to verify our unwinder the properly uses that 'S' flag
> to change the boundary conditions when search for the applicable FDE.
> -------------------------------------------------------------------------
> So it appears that if this gets fixed, it will likely only be for darwin11.

what's the expectation/status here?

I see that these test-cases still fail on x86_64-darwin12, with the latest
XCode tools.

[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0

[howarth at nitro dot med.uc.edu]

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

--- Comment #11 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
(In reply to Iain Sandoe from comment #10)
> 
> what's the expectation/status here?
> 
> I see that these test-cases still fail on x86_64-darwin12, with the latest
> XCode tools.

These failures are still present in darwin13. Also, I see these failures are
also present in current gcc trunk on x86_64-unknown-freebsd8.4 and
i386-unknown-freebsd10.0. It might be interesting to find out why these fail on
freebsd.

[Bug target/48097] gcc sometimes generates code that uses the buggy libgcc_s unwinder on darwin (originally exposed by Throw_2 failures in libjava testsuite under Xcode 4.0)

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |iains at gcc dot gnu.org
           Keywords|                            |patch
                 CC|                            |egallager at gcc dot gnu.org
             Status|SUSPENDED                   |ASSIGNED
                URL|                            |https://gcc.gnu.org/piperma
                   |                            |il/gcc-patches/2021-Februar
                   |                            |y/565950.html

--- Comment #17 from Eric Gallager <egallager at gcc dot gnu.org> ---
Iain has a patch for this now:
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565950.html

[Bug target/48097] gcc sometimes generates code that uses the buggy libgcc_s unwinder on darwin (originally exposed by Throw_2 failures in libjava testsuite under Xcode 4.0)

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097

--- Comment #18 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

https://gcc.gnu.org/g:491d5b3cf8216f9285a67aa213b9a66b0035137b

commit r11-7443-g491d5b3cf8216f9285a67aa213b9a66b0035137b
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Mon Jan 18 20:09:10 2021 +0000

    dwarf2unwind : Force the CFA after remember/restore pairs [44107/48097].

    This address one of the more long-standing and serious regressions
    for Darwin.  GCC emits unwind code by default on the assumption that
    the unwinder will be (of have the same capability) as the one in the
    current libgcc_s.  For Darwin platforms, this is not the case - some
    of them are based on the libgcc_s from GCC-4.2.1 and some are using
    the unwinder provided by libunwind (part of the LLVM project). The
    latter implementation has gradually adopted a section that deals with
    GNU unwind.

    The most serious problem for some of the platform versions is in
    handling DW_CFA_remember/restore_state pairs.  The DWARF description
    talks about these in terms of saving/restoring register rows; this is
    what GCC originally did (and is what the unwinders do for the Darwin
    versions based on libgcc_s).

    However, in r118068, this was changed so that not only the registers
    but also the current frame address expression were saved.  The unwind
    code assumes that the unwinder will do this; some of Darwin's unwinders
    do not, leading to lockups etc.  To date, the only solution has been
    to replace the system libgcc_s with a newer one which is not a viable
    solution for many end-users (since that means overwritting the one
    provided with the system installation).

    The fix here provides a target hook that allows the target to specify
    that the CFA should be reinstated after a DW_CFA_restore.  This fixes
    the issue (and also the closed WONTFIX of 44107).

    (As a matter of record, it also fixes reported Java issues if
     backported to GCC-5).

    gcc/ChangeLog:

            PR target/44107
            PR target/48097
            * config/darwin-protos.h (darwin_should_restore_cfa_state): New.
            * config/darwin.c (darwin_should_restore_cfa_state): New.
            * config/darwin.h (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New.
            * doc/tm.texi: Regenerated.
            * doc/tm.texi.in: Document TARGET_ASM_SHOULD_RESTORE_CFA_STATE.
            * dwarf2cfi.c (connect_traces): If the target requests, restore
            the CFA expression after a DW_CFA_restore.
            * target.def (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New hook.

[Bug target/48097] gcc sometimes generates code that uses the buggy libgcc_s unwinder on darwin (originally exposed by Throw_2 failures in libjava testsuite under Xcode 4.0)

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097

--- Comment #19 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Iain D Sandoe
<iains@gcc.gnu.org>:

https://gcc.gnu.org/g:c3d51b2d2382d44b0463b7ebaf12f3b788c9027e

commit r10-9502-gc3d51b2d2382d44b0463b7ebaf12f3b788c9027e
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Mon Jan 18 20:09:10 2021 +0000

    dwarf2unwind : Force the CFA after remember/restore pairs [44107/48097].

    This address one of the more long-standing and serious regressions
    for Darwin.  GCC emits unwind code by default on the assumption that
    the unwinder will be (of have the same capability) as the one in the
    current libgcc_s.  For Darwin platforms, this is not the case - some
    of them are based on the libgcc_s from GCC-4.2.1 and some are using
    the unwinder provided by libunwind (part of the LLVM project). The
    latter implementation has gradually adopted a section that deals with
    GNU unwind.

    The most serious problem for some of the platform versions is in
    handling DW_CFA_remember/restore_state pairs.  The DWARF description
    talks about these in terms of saving/restoring register rows; this is
    what GCC originally did (and is what the unwinders do for the Darwin
    versions based on libgcc_s).

    However, in r118068, this was changed so that not only the registers
    but also the current frame address expression were saved.  The unwind
    code assumes that the unwinder will do this; some of Darwin's unwinders
    do not, leading to lockups etc.  To date, the only solution has been
    to replace the system libgcc_s with a newer one which is not a viable
    solution for many end-users (since that means overwritting the one
    provided with the system installation).

    The fix here provides a target hook that allows the target to specify
    that the CFA should be reinstated after a DW_CFA_restore.  This fixes
    the issue (and also the closed WONTFIX of 44107).

    (As a matter of record, it also fixes reported Java issues if
     backported to GCC-5).

    gcc/ChangeLog:

            PR target/44107
            PR target/48097
            * config/darwin-protos.h (darwin_should_restore_cfa_state): New.
            * config/darwin.c (darwin_should_restore_cfa_state): New.
            * config/darwin.h (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New.
            * doc/tm.texi: Regenerated.
            * doc/tm.texi.in: Document TARGET_ASM_SHOULD_RESTORE_CFA_STATE.
            * dwarf2cfi.c (connect_traces): If the target requests, restore
            the CFA expression after a DW_CFA_restore.
            * target.def (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New hook.

    (cherry picked from commit 491d5b3cf8216f9285a67aa213b9a66b0035137b)

[Bug target/48097] gcc sometimes generates code that uses the buggy libgcc_s unwinder on darwin (originally exposed by Throw_2 failures in libjava testsuite under Xcode 4.0)

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097

--- Comment #20 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Iain D Sandoe
<iains@gcc.gnu.org>:

https://gcc.gnu.org/g:6cfcaa4609ee3e3557ddf50fda00fdf9a5fc07e4

commit r9-9492-g6cfcaa4609ee3e3557ddf50fda00fdf9a5fc07e4
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Mon Jan 18 20:09:10 2021 +0000

    dwarf2unwind : Force the CFA after remember/restore pairs [44107/48097].

    This address one of the more long-standing and serious regressions
    for Darwin.  GCC emits unwind code by default on the assumption that
    the unwinder will be (of have the same capability) as the one in the
    current libgcc_s.  For Darwin platforms, this is not the case - some
    of them are based on the libgcc_s from GCC-4.2.1 and some are using
    the unwinder provided by libunwind (part of the LLVM project). The
    latter implementation has gradually adopted a section that deals with
    GNU unwind.

    The most serious problem for some of the platform versions is in
    handling DW_CFA_remember/restore_state pairs.  The DWARF description
    talks about these in terms of saving/restoring register rows; this is
    what GCC originally did (and is what the unwinders do for the Darwin
    versions based on libgcc_s).

    However, in r118068, this was changed so that not only the registers
    but also the current frame address expression were saved.  The unwind
    code assumes that the unwinder will do this; some of Darwin's unwinders
    do not, leading to lockups etc.  To date, the only solution has been
    to replace the system libgcc_s with a newer one which is not a viable
    solution for many end-users (since that means overwritting the one
    provided with the system installation).

    The fix here provides a target hook that allows the target to specify
    that the CFA should be reinstated after a DW_CFA_restore.  This fixes
    the issue (and also the closed WONTFIX of 44107).

    (As a matter of record, it also fixes reported Java issues if
     backported to GCC-5).

    gcc/ChangeLog:

            PR target/44107
            PR target/48097
            * config/darwin-protos.h (darwin_should_restore_cfa_state): New.
            * config/darwin.c (darwin_should_restore_cfa_state): New.
            * config/darwin.h (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New.
            * doc/tm.texi: Regenerated.
            * doc/tm.texi.in: Document TARGET_ASM_SHOULD_RESTORE_CFA_STATE.
            * dwarf2cfi.c (connect_traces): If the target requests, restore
            the CFA expression after a DW_CFA_restore.
            * target.def (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New hook.

    (cherry picked from commit 491d5b3cf8216f9285a67aa213b9a66b0035137b)

[Bug target/48097] gcc sometimes generates code that uses the buggy libgcc_s unwinder on darwin (originally exposed by Throw_2 failures in libjava testsuite under Xcode 4.0)

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #21 from Iain Sandoe <iains at gcc dot gnu.org> ---
fixed on all open branches.
distributions using earlier branches would be advised to back-port to those.