Mark Wielaard wrote: > Hi Andrew, > > On Thu, 2008-06-12 at 14:49 +0100, Andrew Haley wrote: >> Mark Wielaard wrote: >>>> + 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. > > Ah, programmer mistake, right, people still do that in C :) > >>> 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. > > It helps if you attach to a (stuck) vm with an debugger. I don't care > too much about it (some distros like fedora actually always generate > full unwind tables from their system gcc anyway). I mainly wondered if > there was any difference between what -fnon-call-exceptions did and > -fasynchronous-unwind-tables. The coverage of the later is bigger I > believe, but maybe the first does more stuff that you need for the > actual exceptions?
No, I don't think so. I'll use -fasynchronous-unwind-tables, which satisfies both requirements. Andrew.
