Hi Dale,
> > 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)
I'm not sure what you mean: there is a handler: it just rethrows
the exception. This is not very interesting of course, but it's
still a handler. Or do you mean something different when you talk
of a handler?
> 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.
I also don't understand this: why is Unwind_Resume looking at where
the exception's handler is? The handler used for the caught exception
should be irrelevant to it. It sounds like the unwinder thinks that
the Unwind_Resume is in the same eh region as the original throwing
call.
> 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.
How is catch-all then rethrow supposed to work then? Are you sure
that this isn't simply a bug in where labels are placed etc, the
frame info or the exception table setup etc?
> (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.
Are you saying that the Darwin unwinder doesn't have the special
cleanup logic? If so you could indeed push a cleanup rather than
a catch-all on Darwin.
> Could you point me to an example that should fail?
Sure - run the testsuite on linux with -enable-correct-eh-support
changed to -enable-eh in Makefile.programs. Then apply your patch,
run again and analyse the failures. I will do this and send you
a reduced example (I used to have some but I don't remember what
I did with them).
Ciao,
Duncan.