Use of -fno-exceptions

Use of -fno-exceptions

[Ian Cottam]

We use gcc 2.95.3.
To save space in our very large build we use  -fno-exceptions.
Now, a colleague says he needs exceptions in one, localized class. Is it
safe to just compile this class/file (but no other) with the
default -fexceptions ?
Thanks for any help.
-Ian
Ian Cottam

Re: Use of -fno-exceptions

[Joe Buck]

> We use gcc 2.95.3.
> To save space in our very large build we use  -fno-exceptions.
> Now, a colleague says he needs exceptions in one, localized class. Is it
> safe to just compile this class/file (but no other) with the
> default -fexceptions ?

The exceptions support is needed to do a cleanup.  When an exception
is thrown, the stack gets popped one frame at a time and destructors
are called, up to the point where the exception is caught.  For this
to work properly, every possible call site that could be involved
would need to be compiled with exceptions enabled.  You may be able
to make a mixed environment work, but it will be tricky and perhaps
unstable.

Re: Use of -fno-exceptions

[Jeff Sturm]

On Mon, 19 Nov 2001, Joe Buck wrote:
> > We use gcc 2.95.3.
> > To save space in our very large build we use  -fno-exceptions.
> > Now, a colleague says he needs exceptions in one, localized class. Is it
> > safe to just compile this class/file (but no other) with the
> > default -fexceptions ?
> 
> The exceptions support is needed to do a cleanup.  When an exception
> is thrown, the stack gets popped one frame at a time and destructors
> are called, up to the point where the exception is caught.  For this
> to work properly, every possible call site that could be involved
> would need to be compiled with exceptions enabled.  You may be able
> to make a mixed environment work, but it will be tricky and perhaps
> unstable.

Is that strictly true?  My understanding is that one could use
sjlj-exceptions and throw over any call frame, compiled with -fexceptions
or not, because setjmp/longjmp processing doesn't require explicit unwind
info.

For the default EH model, your statement above is correct.

Jeff

Re: Use of -fno-exceptions

[Joe Buck]

> > The exceptions support is needed to do a cleanup.  When an exception
> > is thrown, the stack gets popped one frame at a time and destructors
> > are called, up to the point where the exception is caught.  For this
> > to work properly, every possible call site that could be involved
> > would need to be compiled with exceptions enabled.  You may be able
> > to make a mixed environment work, but it will be tricky and perhaps
> > unstable.
> 
> Is that strictly true?  My understanding is that one could use
> sjlj-exceptions and throw over any call frame, compiled with -fexceptions
> or not, because setjmp/longjmp processing doesn't require explicit unwind
> info.

For a call frame where a destructor must be called, even with sjlj you
need -fexceptions to get that destructor called.  Otherwise there will
be a memory leak and possibly some resource that should be freed won't
be (like a lock for a critical region, if managed with a constructor/
destructor pair).

Re: Use of -fno-exceptions

[Jeff Sturm]

On Mon, 19 Nov 2001, Joe Buck wrote:
> > > The exceptions support is needed to do a cleanup.  When an exception
> > > is thrown, the stack gets popped one frame at a time and destructors
> > > are called, up to the point where the exception is caught.  For this
> > > to work properly, every possible call site that could be involved
> > > would need to be compiled with exceptions enabled.  You may be able
> > > to make a mixed environment work, but it will be tricky and perhaps
> > > unstable.
> > 
> > Is that strictly true?  My understanding is that one could use
> > sjlj-exceptions and throw over any call frame, compiled with -fexceptions
> > or not, because setjmp/longjmp processing doesn't require explicit unwind
> > info.
> 
> For a call frame where a destructor must be called, even with sjlj you
> need -fexceptions to get that destructor called.  Otherwise there will
> be a memory leak and possibly some resource that should be freed won't
> be (like a lock for a critical region, if managed with a constructor/
> destructor pair).

You're right.  I was thinking about the common case in which I have a C
library compiled without -fexceptions.  Since C doesn't have destructors,
I can get by with sjlj-exceptions.

Jeff