similar to: [RFC] [Windows SEH] Local_Unwind (Jumping out of a _finally)

Hi, This is a spin-off of previous Windows SEH RFC below. This RFC only focus on supporting HW Exception Handling. A detailed implementation can be seen in here: https://github.com/tentzen/llvm-project/commit/8a2421c274b683051e456cbe12c177e3b934fb5e It passes all MSVC SEH suite (excluding those with “Jumping out of _finally” ( _Local_Unwind)). Thanks, --Ten **** The rules for C code: ****

Resending; I accidentally dropped llvm-dev. -Eli From: Eli Friedman Sent: Wednesday, April 1, 2020 1:01 PM To: Ten Tzen <tentzen at microsoft.com> Cc: aaron.smith at microsoft.com Subject: RE: [EXT] [llvm-dev] [RFC] [Windows SEH] Local_Unwind (Jumping out of a _finally) and -EHa (Hardware Exception Handling) This looks like it outlines the implementation pretty well. For goto in finally,

Hi, Eli, Why are you under the impression that threw_exception() will not be called if optimizations are enabled? I don’t know if the -EHa Spec is clearly described in MSFT Webs. At least this proposal has described the rules for both C & C++ code. The very first rule clearly said that “no exception can move in or out of _try region., i.e., no potential faulty instruction can be moved

* When a goto in a _finally occurs, we must "unwind" to the target code, not just "jump" to target label I'm not sure what you're trying to say here. In the Microsoft ABI, goto out of a catch block also calls into the unwinder. We have to run any destructors, and return from the funclet (catchret/cleanupret). * The call inside a _try is an invoke with EH

Reply inline From: Ten Tzen <tentzen at microsoft.com> Sent: Wednesday, April 1, 2020 3:54 PM To: Eli Friedman <efriedma at quicinc.com>; llvm-dev <llvm-dev at lists.llvm.org> Cc: aaron.smith at microsoft.com Subject: [EXT] RE: [llvm-dev] [RFC] [Windows SEH] Local_Unwind (Jumping out of a _finally) and -EHa (Hardware Exception Handling) ? For goto in finally, why are you

Hi, all, The intend of this thread is to complete the support for Windows SEH. Currently there are two major missing features: Jumping out of a _finally and Hardware exception handling. The document below is my proposed design and implementation to fully support SEH on LLVM. I have completely implemented this design on a branch in repo:

As stated in the design paragraph, this design does not intend to model precise CFG at instruction level since it’s complicated and unnecessary. As long as we comply C and C++ rules listed below, we achieve -EHa semantic. There is NO need to precisely model HW exception control flow at instruction-level. Your example about memcpy() is just a bug in current implementation. I will fix it so that

Hello everyone, I was wondering what is the status regarding exceptions for the windows-msvc target? The corresponding part of the documentation (llvm/decs/ExceptionHandling.rst) hasn't been updated since 2015, was there any progress since? This is most likely known, but there's significant divergence between the behavior of MSVC cl.exe and clang-cl.exe: Consider: void crash() {

Hi Reid, I'm trying to get a "big picture" view of everything that needs to be done for clang and llvm to support SEH and C++ exception handling for the "msvc" environment. I've put together a list, including work in progress, but I'm guessing that I've missed some details. Can you look this over and tell me if it matches your idea of what needs to be done?

Here is a wiki page and git repo with an implementation of SEH that passes all the tests for x86. We're looking for feedback before putting a patch on Phabricator. https://github.com/tentzen/llvm-project https://github.com/tentzen/llvm-project/wiki On Mon, Nov 18, 2019 at 10:59 PM Gaier, Bjoern <Bjoern.Gaier at horiba.com> wrote: > Thank you for this Aaron! > > > > In

At Microsoft we open sourced some of our compiler tests for exception handling on github. https://github.com/microsoft/compiler-tests We are looking into what it would take to get these to work with clang-cl. I’m planning to share a design document on the mailing list soon. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, I have a question about the IR model for SEH filters (as I want to use the same model for CLR filters). In particular, when an outer filter is invoked before entering an inner finally, which piece of IR reflects the filter's side-effects? To take a concrete example, consider this C code: void foo() { int x; __try { x = 0; __try { x = 2; may_throw(); }

Moving this month old RFC to llvmdev. Not sure why I sent this to cfe-dev in the first place... --- Based on code review discussion from John, he thinks filter expressions should be emitted into the body of the function with the try, rather than being outlined by the frontend. Instead of having the frontend create filter functions, we would use labels in place of typeinfo. The IR would look

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

Hi Jb, It's good to see someone step up and take a shot as this again. I dropped this because it seems to me it wasn't a high priority task for LLVM/Clang. Implementing SEH is more of LLVM work than Clang work. For 32-bit SEH, there are prologue/epilogue instruction sequence to emit, setting try-level ([ebp-4]), recovering EBP ([ebp-18h]), and all these can only happen in LLVM, not

Is LLVM expressive enough to represent asynchronous exceptions? --------------------------------------------------------------- Summary: Need new LLVM instructions or extending of all instructions. C++ exceptions are synchronous: the compiler knows when/where they are being raised. Asynchronous exceptions can be raised at any time. For example, an integer divide-by-zero may raise an

Can you clarify what you mean by "real SEH handling"? My company has me looking at this in the hopes that I can make LLVM capable of building windows drivers. If you mean "visual c++ style SEH", I'm fairly sure that isn't necessary for my purposes, but it would be nice. If you mean "something that works at all," then your concern about generalizing LLVM

The limitation with the "Reviewed by" line is that if you just use `arc` it indicates who was added as reviewer on the revision, but not who approved it. Because of this, I am wary of relying on this line for anything. If you want to know who reviewed a change, better click on the Differential Revision link and go to the source of truth. -- Mehdi On Thu, Jan 2, 2020 at 10:44 AM

I'm sure I've seen many commits with both "Reviewed by:" and "Reviewers:" tags, which look to have been done with arc (though I can't be sure). How were those generated? On Sat, 4 Jan 2020 at 19:12, David Blaikie <dblaikie at gmail.com> wrote: > Yeah, I tend to prune it down myself - and if the list has only one name > on it, it's usually a pretty

I also find the "Reviewed by" tag useful (as well as the review link), for the same reasons. In fact, I don't even use arcanist to push commits, so I do it all by hand, and only include the "Reviewed by" and "Differential Revision" tags. On Fri, 27 Dec 2019 at 20:55, David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I don't think