This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: RFC: C++ PATCH to stop emitting code for throw() by default


On Mon, 22 Mar 2010, Mark Mitchell wrote:

> >> Also, how do we know that emitting nothing will result in a call to
> >> terminate?  Perhaps our caller has an exception handler that will catch
> >> this exception?
> > 
> > Because the function can't throw, no unwind information is emitted for
> > calls to the function, so the unwinder can't unwind through the call and
> > calls terminate.
> 
> Isn't that a GCC-specific assumption?  So that we can't be sure that
> this will work with another compiler that implements the ABI?  If so,
> that seems like another reason that this should not be a default.

Relying on the absence of unwind information without explicitly ensuring 
the absence in a particular case seems generally problematic; unwind 
information may be present where not strictly necessary, by default on a 
particular platform, or for use with other tools for purposes such as 
profiling rather than just for exception handling.

See for example <http://sourceware.org/bugzilla/show_bug.cgi?id=2682> 
where in comment#4 I give an example of a testcase that fails on x86_64 
because the unwind-info-by-default on that platform means an exception 
thrown in an atexit handler can be caught in main, contrary to what the 
C++ standard requires.  atexit can't throw, but still has unwind 
information; fixing this would require a way to mark the callers of atexit 
handlers as explicitly not-unwindable.

-- 
Joseph S. Myers
joseph@codesourcery.com


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