<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>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.</p>
<p>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.</p>
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 1/19/18 2:27 PM, Reid Kleckner
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACs=tyKe8JzsdzyVvRG-ncbnsJRLOM-cBDHsnofkY0nA+Ze6WQ@mail.gmail.com">
<div dir="ltr">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.
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Jan 19, 2018 at 7:06 AM, David
Chisnall via llvm-dev <span dir="ltr"><<a
href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">On 19 Jan 2018, at 14:48, John Reagan via
llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:<br>
><br>
> OpenVMS' EH model is for full asynchronous
prologue/epilogue EH. We do more<br>
> than just program-level EH, but have to deal with OS
events (timers going off,<br>
> asynch I/O completion, mailboxes filled with data,
etc.) which could result in<br>
> an unwind occurring.<br>
><br>
> We're just about finished with our proposal for
extending the x86 compact EH data<br>
> format to cover all the cases plus the desire to
create the additional .cfi directives.<br>
> Feedback and pointers will be most helpful. Look for
this as a new thread sometime<br>
> early next week (we're having our final review on
Monday before I post it).<br>
<br>
</span>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<br>
<br>
int i = 0;<br>
try {<br>
i++;<br>
foo();<br>
i++;<br>
} catch (…) {<br>
return i;<br>
}<br>
<br>
The SSA form of this will look something more like this:<br>
<br>
int i0 = 0;<br>
try {<br>
i1 = 1;<br>
foo();<br>
i2 = 2;<br>
} catch (…) {<br>
return 1;<br>
}<br>
<br>
But if you are allowed to throw exceptions on any
instruction, then you end up with something more like:<br>
<br>
int i0 = 0;<br>
try {<br>
a:<br>
i1 = 1;<br>
b:<br>
foo();<br>
c:<br>
i2 = 2;<br>
} catch (…) {<br>
return phi({a,0},{b, i1},{c,i2});<br>
}<br>
<br>
With the current structure of LLVM’s exception handling, the
fact that i may be incremented after the only invoke
instruction is not visible.<br>
<br>
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.<br>
<br>
David<br>
<div class="HOEnZb">
<div class="h5"><br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>