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

2017-10-19 Thread egallager at gcc dot gnu.org
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

2017-07-19 Thread egallager at gcc dot gnu.org
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

2016-10-25 Thread iains at gcc dot gnu.org
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

2016-10-25 Thread egall at gwmail dot gwu.edu
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

2013-09-16 Thread 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] new Throw_2 failures in libjava under Xcode 4.0

2013-09-14 Thread 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

2012-02-25 Thread 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

2011-03-18 Thread 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

2011-03-18 Thread 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

2011-03-18 Thread 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

2011-03-18 Thread 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

2011-03-17 Thread 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

2011-03-17 Thread 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

2011-03-12 Thread 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

2011-03-12 Thread 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, 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(JArrayjava::lang::String**) + 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)