similar to: Exception handling support for a target

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

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.

Hi all, We're at the point in our port of OpenVMS to x86-64 that we're working on the unwind code.  The current ABI and the current codebase doesn't have enough support for true asynchronous unwinding from any point (most notably in the prologue/epilogue) in the code that OpenVMS needs.  We're working on a set of changes to the compact unwind information to handle the additional

Here is our proposal to extend/enhance the x86-64 compact unwind descriptors to fully describe the prologue/epilogue for asynchronous unwinding.  I believe there are missing/lacking CFI directives as well, but I'll save that for another thread. Asynchronous Compact Unwind Descriptors Ron Brender, VMS Software, Inc. Revised January 25, 2018 1  Introduction This document proposes means to

John and Ron, I developed the original compact unwind implementation for macOS 10.6 back in 2009. I tried to leave space in the design to support finer grain exception handling such as for asynchronous or for the shrink wrap optimization. The idea I had at the time was instead of having just one 32-bit compact unwind info per function, there could be an array of them each covering a different

Hi Nick, It is a pleasure to be in contact with the creator of the compact unwind approach! I can see how an array of 32-bit unwind blocks could be used to describe each distinct point within a function (within a prolog in particular). But then you end up with six or seven or more such blocks for a large percentage of functions, don't you? Seems like a lot of additional space for something

Folks, I'm sorry for getting at this again, but this will not be the last discussion on the topic, so let's just get to business. We're about to merge the last critical patch to make EHABI compatible with other EH mechanisms in LLVM (D3079), and that has unearthed a few issues with the function attributes. Logan's blog post [1] contains a proposal to split unwinding from

2018-01-16 21:03 GMT+08:00 Tim Northover <t.p.northover at gmail.com>: > On 16 January 2018 at 12:23, 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw> wrote: > > Do we have to emit directives in the epilogue, too? One of my test case > fail > > due to the directives in the epilogue have been executed. After removing > > them from epilogue, the exception is caught as

On 16 January 2018 at 12:23, 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw> wrote: > Do we have to emit directives in the epilogue, too? One of my test case fail > due to the directives in the epilogue have been executed. After removing > them from epilogue, the exception is caught as expected. Emitting directives in the epilogue is hard because the directives apply to all instructions

Hi John & Ron, I read through the proposal and had a couple of quick observations. 1. The proposed encoding assumes that the epilogue instructions always come at the end of the function -- or rather, just before the next function. If there is a stack protector __stack_chk_fail sequence, or there is NOP padding between functions, then the epilogue cannot be expressed. The proposed encoding

2018-01-16 18:18 GMT+08:00 Tim Northover <t.p.northover at gmail.com>: > On 15 January 2018 at 12:49, 陳韋任 via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > > - CFI directives: > > > > This is for .eh_frame section. Basically all the targets insert CFI > > directives in FrameLowering, but I am not sure exactly when/where I > should > > do

On Fri, Sep 18, 2009 at 11:13:52AM -0700, Nick Kledzik wrote: > > The important thing is that only one unwinder is used. The > _Unwind_Context data structure is different between the darwin and FSF > implementations, so you can't pass it between two different > implementations. Since darwin uses two-level namespace and swapping in > a new libgcc_s.dylib at runtime

Hi I'm working on the XCore target and am having difficulty building libgcc. Background: If I use a libgcc built by llvm3.0-gcc with my current clang-llvm3.3 compiler, exceptions 'seem' to work. Trying to rebuild libgcc however breaks exception handling - they aren't caught! I thus assumed I needed to focus on the unwind code and particularly functions that call

On 16 January 2018 at 13:41, 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw> wrote: > bar: > > .cfi_def_cfa_offset 16 > epilogue > > _Unwind_Resume > > > > The lookup phase of exception handling is fine. However, something goes > wrong in cleanup phase. The reason is the unwinder evaluates CFI directives > until _Unwind_Resume, and `.cfi_def_cfa_offset

On 11-06-02 6:56 AM, Anton Korobeynikov wrote: > Hi Chip, > >> Because of all this, it's hard to reconstruct the SEH information from >> the MachineMove array. I have thought about adding a new array specific >> to SEH information, but I'm not sure how you guys would feel about that. >> Any ideas on how to solve this problem? > Same problem with

On 20 March 2014 02:09, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > I think this is just 2. It uses .eh_frame for unwinding proper. The > only difference in .eh_frame is that there is a personality function > defined. If there is no debug information, it should still be possible to unwind the stack via the saved LR on the stack, no? If there is only line info, you

On 6 February 2014 19:21, Richard Smith <richard at metafoo.co.uk> wrote: > > if (nounwind) > can't unwind > can't unwind == unwind table + no EH directives + no EH table if (uwtable || (!nounwind && need uwtable to unwind)) > unwind table > "need unwind table to unwind" is probably true in almost all cases. At least in all where

On Sat, May 16, 2015 at 7:29 AM, Steve Cheng <steve.ckp at gmail.com> wrote: > On 2015-05-15 18:37:58 -0400, Reid Kleckner said: > > After a long tale of sorrow and woe, my colleagues and I stand here >> before you defeated. The Itanium EH representation is not amenable to >> implementing MSVC-compatible exceptions. We need a new representation that >> preserves

Folks, We're having some discussions about the behaviour of exception handling and Dwarf sharing unwind logic, tables, etc. and it seems that the code around it wasn't designed with any particular goal in mind, but evolved (like the EHABI) and now we're seeing the results from it. The problems below are assuming C vs. C++, but it actually apply to any possibly-exceptional vs.

Hi Keith, Anton, Logan, Last time we spoke about ARM unwinding, we agreed to have both CFI and directive variants in ARM, so that both EH and debuggers/profilers could correctly unwind the stack. The problem, obviously, is that we now have redundant information and I decided to have a go commoning them up. One of the issues, I think, is GNU compatibility (so GAS can generate the tables correctly