[llvm-dev] Exception handling support for a target

John Reagan via llvm-dev llvm-dev at lists.llvm.org
Fri Jan 19 06:48:33 PST 2018


> 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>


More information about the llvm-dev mailing list