[LLVMdev] Darwin vs exceptions

[Dale Johannesen]

On Dec 8, 2007, at 12:51 AM, Duncan Sands wrote:

> Hi Chris,
>
>> ... Claiming that a function has a
>>> catch-all handler when it does
>>> not causes the unwinder to go into a loop.
>
> this is the bit I don't understand.  Why does it go
> into a loop?  How can the unwinder possibly know that
> the original code did not have a catch-all, since we
> tell it which catches there are and we say: there is
> a catch-all!

The unwinder works by doing a stack crawl to find a handler.  Since  
we're telling it every eh-selector is a catch-all handler, it finds  
one immediately (that is not there) and caches where it thinks it  
is.  That code (cleanup or whatever) is executed and ends by reaching  
Unwind_Resume, which tries to resume at where it thinks the handler  
is.  Which is back at the same code from which we reached  
Unwind_Resume.  This worked OK when we were caching the IP because  
the IP of the throw and Unwind_Resume call were different, but when  
caching the CFA they are the same, which confuses Unwind_Resume.
(This is darwin's unwinder but I think the patch I quoted is the only  
relevant change to generic gcc code.
Could be wrong.)

>>> -  lang_eh_catch_all = return_null_tree;
>>> +/*  lang_eh_catch_all = return_null_tree;*/
>
>> Ok, cool :)  Duncan, Anton, what do you guys think about this?
>
> This is wrong - it breaks the semantics of invoke and causes
> eh to not work properly in some cases (see my email to Dale).

Well, it works a lot better on Darwin than what's there now.  I  
believe telling the unwinder there is a cleanup is sufficient to get  
control always transferred to the secondary label on the invoke.

Could you point me to an example that should fail?