This is the mail archive of the
mailing list for the GCC project.
Re: Bypassing jump optimization
> I have looked at these files and my current opinion is that it is best to not
> share much of the code for the complex and flexible gcc exception handling
> mechanisms. SEH is simple compared to fx. c++ exception handling. It is
> basicly just a transfer of execution from the OS to an exception filter
> routine, which then signals the OS, wether execution should resume at the
> instruction that faulted, or an exception handler should be run to cleanup
> from the operation that caused the fault.
> Because it is the OS (actually the MS Visual C++ runtime library dll) that
> calls the exception filter and not the gcc generated code, the label is not
> referenced and thus discarded by gcc.
This is not too different from the exception handling itself for noncall
events (Java has concept, where exception is throwed by division by zero
etc and gcc implements it).
Basically I believe you should share the interface of exception handling
to backend. The exception handling regions and handlers has a lot of
special properties (such as that code motion needs to be limited
across their boundaries and handlers are reachable as long as some
region refering to the contain something than can throw).
Gcc backend knows that and it has been hard work to get it working right.
Basically you can claim gcc that it is the "normal exception" and only
make the exception handling code to emit something different.
We already have concept of setjmp/longjmp exception handling, your case
appears to be quite similar.
> I'm new to gcc and does not have a complete overview of gcc. If anyone
> disagrees about not sharing code with the current exception mechanisms,
> please say so.
> - Casper Hornstrup