This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCJ/minGW produced executables and linux/wine


Jeff Sturm writes:
 > On Tue, 4 Mar 2003, Andrew Haley wrote:
 > >  > I think this test isn't quite right:
 > >  >
 > >  > if test $can_unwind_signal = no && test $enable_sjlj_exceptions = no; then
 > >  >   CHECKREFSPEC=-fcheck-references
 > >  >   ...
 > >  >
 > >  > since it gives no assurances that signal handling a.k.a. exception filters
 > >  > work at all.
 > >
 > > The test is correct, but it may need to be overriden on some targets.
 > > If we're using sjlj, we shouldn't need to use -fcheck-references.
 > 
 > Shouldn't, no.  My problem is that I don't have a viable debugger.  I did
 > try one test on a bonafide Windows machine with the same results though.
 > 
 > However it seems to me that targets supporting a SIGSEGV handler or
 > equivalent are the exception, not the rule,

That's true only of targets to which gcj has not yet been ported.  A
gcj port absolutely requires a working SEGV handler.
-fcheck-references is a half-baked workaround.

 > in which case -fcheck-references would be more appropriate as the
 > configuration default except on targets for which we know better.

It already is.

-fcheck-references is the configuration default unless we're using
sjlj.  sjlj is deprecated in gcc and will not be supported for ever.


 > > Please let me know which tests still fail.

Throw_2 passes?

Wow, that's *really* weird.  It's supposed to detect the case when
there is not a working SEGV handler, even with -fcheck-references.

That is bad news.  I would love to know _how_ that test passes.

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]