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)
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)
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)
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.
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.
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.
(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.
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.
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.
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
(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.
(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.
GCJ has been removed from GCC 7. But on the other hand this isn't really so much a java bug itself as it is an unwinding bug that java just happened to be the one to tickle. So is it worth keeping this bug open?
(In reply to Eric Gallager from comment #12) > GCJ has been removed from GCC 7. But on the other hand this isn't really so > much a java bug itself as it is an unwinding bug that java just happened to > be the one to tickle. So is it worth keeping this bug open? agreed it's an unwinder bug, I suppose we need a non-Java reproducer. As of Darwin11, nothing should be using the libgcc_s unwinder (and really it shouldn't be used for darwin10). The broken unwinder in the darwin9 libgcc_s can't be easily fixed (44107) - and the resolution there is to update the installed lib. It's possible that we're going to struggle to get a fix unless/until we can make output compatible with the compact unwinder. We can leave this open, but as stated, someone should try to find a non-Java reproducer.
(In reply to Iain Sandoe from comment #13) > > We can leave this open, but as stated, someone should try to find a > non-Java reproducer. Compromise between closing and leaving open: I'll change the status to SUSPENDED until there's a non-Java reproducer.
(In reply to Iain Sandoe from comment #13) > (In reply to Eric Gallager from comment #12) > > GCJ has been removed from GCC 7. But on the other hand this isn't really so > > much a java bug itself as it is an unwinding bug that java just happened to > > be the one to tickle. So is it worth keeping this bug open? > > agreed it's an unwinder bug, I suppose we need a non-Java reproducer. As of > Darwin11, nothing should be using the libgcc_s unwinder (and really it > shouldn't be used for darwin10). The broken unwinder in the darwin9 > libgcc_s can't be easily fixed (44107) - and the resolution there is to > update the installed lib. > > It's possible that we're going to struggle to get a fix unless/until we can > make output compatible with the compact unwinder. > > We can leave this open, but as stated, someone should try to find a > non-Java reproducer. (just checking back, and for reference, bug 44107 was closed as WONTFIX)
(In reply to Eric Gallager from comment #14) > (In reply to Iain Sandoe from comment #13) > > > > We can leave this open, but as stated, someone should try to find a > > non-Java reproducer. > > Compromise between closing and leaving open: I'll change the status to > SUSPENDED until there's a non-Java reproducer. Also retitling to be more accurate
Iain has a patch for this now: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565950.html
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.
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)
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)
fixed on all open branches. distributions using earlier branches would be advised to back-port to those.