llvm dev - Jan 2018 - Exception handling support for a target

> From: Tim Northover via llvm-dev <llvm-dev at lists.llvm.org>
> Emitting directives in the epilogue is hard because the directives
> apply to all instructions after in program-counter order. So if you
> have an epilogue in the middle of a function and emit CFI directives
> saying the registers are back where they were then the unwinder will
> think that applies to the rest of the function too.
>
> To fix that you'd have to emit yet more directives in the basic block
> immeditately following the epilogue. Most people don't bother with
> either because you'd only really need it if you expected to have to
> catch an exception in the epilogue (which is impossible on most
> platforms).
>
>> Also, the
>> directives are also for debug purpose (.debug_frame), right? I guess I
only
>> have to make sure directives work for exception handling, then debug
works
>> as well?
> Yep. Technically you can stop the debugger in the middle of a prologue
> or epilogue, at which point having more fine-grained directives can
> help. In practice there's no real reason to do that so people don't
> emit directives for it (at least not as a high priority).
>
> Cheers.
>
> Tim.
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).

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180119/2e4b0f28/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/2e4b0f28/attachment.sig>

On 19 Jan 2018, at 14:48, John Reagan via llvm-dev <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

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> wrote:
> On 19 Jan 2018, at 14:48, John Reagan via llvm-dev <
> 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
> 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/9eeb32d3/attachment.html>