<br><br><div class="gmail_quote">On Sun, Sep 26, 2010 at 11:49 AM, Renato Golin <span dir="ltr"><<a href="mailto:rengolin@systemcall.org">rengolin@systemcall.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 26 September 2010 13:08, Eugene Toder <<a href="mailto:eltoder@gmail.com">eltoder@gmail.com</a>> wrote:<br>
>  %s = invoke i32 @v(i32 %o) to label %ok<br>
>                   unwind %x to label %catch<br>
> ok:<br>
>  ret i32 %s<br>
><br>
> catch:<br>
>  %type = call i32 @exception_type(i8* %x)<br>
>  %r = icmp eq i32 %type, 255 ; 255 is DivisionByZeroException type<br>
>  br i1 %r, label %bad, label %worse<br>
><br>
> bad:<br>
>  ret i32 -1<br>
><br>
> worse:<br>
>  ret i32 -2<br>
> }<br>
<br>
</div>That could be enough for SJ/LJ (I have no idea), but it certainly is<br>
not for Dwarf exceptions. When an invoke throws an exception, the flow<br>
doesn't go directly to the catch area. First you go to a cleanup area,<br>
where you have to deallocate all temporaries, in which you can also<br>
throw again, or even terminate.<br>
<br>
Then you go the analysis of the exception structure, to see if that's<br>
valid in accordance with the function specification and the<br>
personality routine (when the EH table goes in context). It is only<br>
after that that you go through the catch blocks by: first checking the<br>
type is the same as the catch block is catching for and entering the<br>
block if it is, or jumping to the next type check/catch block.<br>
<br>
At the end, if it was not caught, you have to jump to another cleanup<br>
area before throwing again, and continue with the unwinding cycle on<br>
the caller function. ALL that is generated by the compiler and happen<br>
oblivious to the user's code. The flow only return to the user's code<br>
if you enter in a catch area.<br>
<br>
Which means that, %type is NOT a number, it is a TypeInfo, and it's<br>
not inside the catch area, but rather before it. I assume, in your<br>
example, that the *icmp* is user code. If %x is what came from the<br>
catch (Type& x) {}, you'll have to do one of two things to get %type:<br>
<br>
1. Give the user an intrinsic, which breaks the EH contract<br>
2. Give the type directly, which also breaks the contract (they also<br>
need the value)<br>
<br>
If the *icmp* is not user code, this is even worse, because an<br>
exception handling code automatically generated by the compiler will<br>
be returning a value from a function, completely breaking the EH<br>
contract.<br>
<br>
In other words, this approach will not work with Dwarf exceptions.<br>
<div class="im"><br></div></blockquote><div><br></div><div>For dwarf exception handling tied to gcc's unwinding library, the minimal change to make it work with this new approach would be to replace the call to 'eh.exception' in the one landing pad with a phi node pulling in the 'exception' value of all the invoke instructions. The use of unwind to initiate the throwing of the exception could be bypassed just like it is currently.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<br>
<br>
> I going with invoke instruction that returns exception pointer (which<br>
> feels right to me) maybe this is a good candidate for using union type<br>
<br>
</div>I'm an advocate of re-introducing unions, but in this case I think<br>
it'll rather obfuscate things even more...<br>
<br>
Don't take me wrong, I'm not against the change, really. If the docs<br>
say there's something wrong, I thing we should fix it, but I fear that<br>
the issue is being seen from the sj/lj point of view only (or<br>
mainly)...<br>
<br>
Is there any language front-end (other than C++) using exceptions? We<br>
might consider their views as well...<br>
<br></blockquote><div><br></div><div>My motivation for this change is to support a compiler I am developing as a personal project. My primary development platform is windows where I currently link against either visual studio's, or mingw's runtime. I envision an optional platform agnostic interpretation of the unwind/invoke that would do whatever is necessary to make the value I pass into the unwind instruction come out the invoke instruction with out me needing to concern my self with the implementation. I accept that in this case, for exceptions outside my language, my program will just terminate. I think this is a reasonable limitation, especially if my program was just going to terminate anyway once it got to the root of the call stack and didn't find a handler.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
cheers,<br>
<font color="#888888">--renato<br>
</font></blockquote></div><div><br></div>thanks,<br><div>-Nathan</div>