[llvm-dev] Exception handling support for a target

[John Reagan via llvm-dev]

OpenVMS' non-call exception support on Alpha & Itanium does have some
restrictions.  We'll do some study and attempt to address the concerns
when I post the doc next week.

However, our primary focus is precise exception modelling in the
prologue/epilogue of routines.  You need precise info on the register
saves, stack pointer save/restore, etc. that the unwinder can use.  On
OpenVMS, we don't invoke a routine's personality routine if we're in the
prologue but the prologue isn't finished.  We go up a frame and start
searching there.  This level of support is needed in our system code (C
and BLISS) as well in customer code in Fortran, Pascal, BASIC, COBOL, etc.



On 1/19/18 2:27 PM, Reid Kleckner wrote:
> I think it's valuable to have precise / asynchronous unwind
> information without adding support for non-call exceptions. Profilers
> and debuggers need to be able to unwind the stack from arbitrary
> instruction boundaries, but they don't need to run exception handlers.
> We can still declare that outside the model. Speaking of which,
> barring bugs, we do support precise unwind info on Win64.
>
> Even if we were to support non-call exceptions, we would enumerate the
> set of supported potentially trapping operations that we support, i.e.
> load, store, div, FP ops, etc. The edges would either be explicit, as
> they are today, or implicit. We already have implicit unwind edges out
> of the function from non-nounwind calls, so this isn't as crazy as it
> sounds.
>
> We would definitely say that ADDs, PHIs, and other things don't trap,
> so in your example it wouldn't matter if the value of 'i' was 1 or 0
> if the exception gets raised at 'b'. There would be no
> control-dependent, possibly-unwinding instruction, either unwinding to
> the caller or choosing to run the catch handler would be correct. It's
> equivalent to the asynchronous exception arriving a little sooner or a
> little later, which the outside observer has no way to control.
>
> On Fri, Jan 19, 2018 at 7:06 AM, David Chisnall via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     On 19 Jan 2018, at 14:48, John Reagan via llvm-dev
>     <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>     >
>     > OpenVMS' EH model is for full asynchronous prologue/epilogue
>     EH.  We do more
>     > than just program-level EH, but have to deal with OS events
>     (timers going off,
>     > asynch I/O completion, mailboxes filled with data, etc.) which
>     could result in
>     > an unwind occurring.
>     >
>     > We're just about finished with our proposal for extending the
>     x86 compact EH data
>     > format to cover all the cases plus the desire to create the
>     additional .cfi directives.
>     > Feedback and pointers will be most helpful.  Look for this as a
>     new thread sometime
>     > early next week (we're having our final review on Monday before
>     I post it).
>
>     Are you planning on extending LLVM to add support for non-call
>     exceptions?  Currently, LLVM is not able to produce correct unwind
>     tables for arbitrary exception points because it does not split
>     basic blocks in such a way that values that are created in a basic
>     block will be visible in at the end.  For example, if I do
>
>     int i = 0;
>     try {
>       i++;
>       foo();
>       i++;
>     } catch (…) {
>       return i;
>     }
>
>     The SSA form of this will look something more like this:
>
>     int i0 = 0;
>     try {
>       i1 = 1;
>       foo();
>       i2 = 2;
>     } catch (…) {
>       return 1;
>     }
>
>     But if you are allowed to throw exceptions on any instruction,
>     then you end up with something more like:
>
>     int i0 = 0;
>     try {
>     a:
>       i1 = 1;
>     b:
>       foo();
>     c:
>       i2 = 2;
>     } catch (…) {
>       return phi({a,0},{b, i1},{c,i2});
>     }
>
>     With the current structure of LLVM’s exception handling, the fact
>     that i may be incremented after the only invoke instruction is not
>     visible.
>
>     I’ve never been entirely happy with how LLVM models exceptions, as
>     calls with two possible returns, but extending that model to
>     properly support unwinds through arbitrary instructions will leave
>     us in the degenerate case of having single-instruction basic
>     blocks.  I’d much rather that we split blocks on places where
>     values visible in an exception handler change, rather than on
>     specific places where exceptions are known to be thrown, but this
>     will require moving to a region-based representation of
>     exceptions, which is a lot of work.  Without this, it’s easy to
>     unwind from arbitrary exceptions, unless you care about having the
>     right values in your handlers.
>
>     David
>
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180119/2bede3e3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180119/2bede3e3/attachment.sig>