Mark Wielaard wrote: > Hi Andrew, > > On Wed, 2008-06-11 at 13:23 +0100, Andrew Haley wrote: >> Classpath, when built as part of gcj, doesn't inherit CFLAGS from >> the gcj configury. As as consequence of this, JNI native code is built >> without unwinder data, and backtraces (and exceptions) through native >> code don't work. >> >> The solution for this is to compile all native code with -fexceptions. >> I could make this a gcj-local patch, but I don't want to add to >> Classpath-libgcj divergence, and unwinder data may well be useful >> even in non-gcj builds. It adds a little to the size of the executables >> on disk but it adds nothing to the memory they occupy, and you get a >> chance to have a working backtrace() for debugging. >> >> Classpath has no CFLAGS macro that applies to all native code, so I had >> to add one, EXTRA_CFLAGS. > > I think this approach is good. Thanks. > >> + dnl CFLAGS that are used for all native code. >> + dnl We want to compile everything with unwinder data so that backrace() > > Typo. Backtrace().
OK. >> + dnl will always work. >> + EXTRA_CFLAGS='-fexceptions -fnon-call-exceptions' >> + AC_SUBST(EXTRA_CFLAGS) > > I am afraid you are more qualified in this subject than I am, but would > any non-call-exceptions actually happen in JNI code? Maybe a division by zero trap or a null pointer trap if a programmer made a mistake. It would be nice to get a clean stack trace if that happened. > If you want full > coverage (for usage by a garbage collector or other asynchronous thread > interrupt) wouldn't -fasynchronous-unwind-tables be more appropriate if > you want full coverage? Possibly. I'm certain that gcj can't cope with asynchronous exceptions and I suspect that no other VM can either, but I can use -fasynchronous-unwind-tables. Andrew.
