[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=44107 --- Comment #15 from Eric Gallager --- (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)
[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 egallager at gcc dot gnu.org changed: What|Removed |Added Status|NEW |SUSPENDED CC||egallager at gcc dot gnu.org --- Comment #14 from egallager at gcc dot gnu.org --- (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.
[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 --- Comment #13 from Iain Sandoe --- (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.
[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 --- Comment #12 from Eric Gallager --- 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?
[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 --- Comment #11 from Jack Howarth --- (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] new Throw_2 failures in libjava under Xcode 4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-14 Ever confirmed|0 |1 --- Comment #10 from Iain Sandoe --- (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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 --- Comment #9 from Jack Howarth 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 --- Comment #8 from Jack Howarth 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 --- Comment #7 from Jakub Jelinek 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 --- Comment #6 from Iain Sandoe 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 --- Comment #4 from Jack Howarth 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 --- Comment #3 from Jack Howarth 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 --- Comment #2 from Jack Howarth 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, 0x00010043aa70 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: 0x00010043aa70 libgcj.12.dylib`int java::lang::String::length() at String.java:451 frame #1: 0x000100072ca9 libgcj.12.dylib`double java::lang::VMDouble::parseDouble(java::lang::String*) + 25 at natVMDouble.cc:165 frame #2: 0x0001004391ba libgcj.12.dylib`double java::lang::Double::parseDouble(java::lang::String*) + 26 at Double.java:348 frame #3: 0x00011adc Throw_2.exe`void Throw_2::main(JArray*) + 474 at Throw_2.java:47 frame #4: 0x00010006695e libgcj.12.dylib`void gnu::java::lang::MainThread::call_main() + 206 at natMainThread.cc:54 frame #5: 0x0001000d1e44 libgcj.12.dylib`void gnu::java::lang::MainThread::run() + 68 at MainThread.java:106 frame #6: 0x00010007785a libgcj.12.dylib`_Jv_ThreadRun(java::lang::Thread*) + 42 at natThread.cc:335 frame #7: 0x00010002b322 libgcj.12.dylib`_Jv_RunMain(_Jv_VMInitArgs*, java::lang::Class*, char const*, int, char const**, bool) + 306 at prims.cc:1789 frame #8: 0x00010002b51a libgcj.12.dylib`_Jv_RunMain(java::lang::Class*, char const*, int, char const**, bool) + 26 at prims.cc:1814 frame #9: 0x00010002b553 libgcj.12.dylib`JvRunMain + 19 at prims.cc:1820 frame #10: 0x0001189f Throw_2.exe`main + 61 at ccP0miy8.i:11 frame #11: 0x00011840 Throw_2.exe`start + 52 (lldb)
[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 --- Comment #1 from Jack Howarth 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)