similar to: [RFC] [Windows SEH] Local_Unwind (Jumping out of a _finally) and -EHa (Hardware Exception Handling)

* 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, Per Reid’s feedback, I have separated two SEH missing features. This thread now is only focusing on _local_unwind(), Jumping out of _finally. The design is documented in Wiki here: https://github.com/tentzen/llvm-project/wiki/Windows-SEH:-Local_Unwind-(aka:-Jumping-Out-of-_Finally) The implementation can be seen here:

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

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

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

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, I'm getting: Unhandled exception at 0x00C211F0 in ConsoleApplication830.exe: 0xC00001A5: An invalid exception handler routine has been detected (parameters: 0x00000001). With some fairly simple SEH enabled routine: define i32 @__elements_entry_point_main(%._gt2a_RemObjects_d_Elements_d_System_d_Array_t_1s*) #0 personality i8* bitcast (i32 ()* @_elements_exception_handler to i8*) !dbg

Indeed, it's 32bits x86 and there's no .safeseh or anything like it, even readobj -coff-load-config says nothing: File: ConsoleApplication830.exe Format: COFF-i386 Arch: i386 AddressSize: 32bit Now I know what to look for, thanks! On Mon, Aug 20, 2018, at 18:46, Reid Kleckner wrote: > This is 32-bit x86, right? Sounds like the exception handler did not > appear in the /safeseh

I've modified llvm to emit vc++ compatible SEH structures for my personality on x86/Windows and my handler works fine, but the only thing I can't figure out is how to call these funclets, they look like: Catch: "?catch$3@?0?m3 at 4HA": LBB4_3: # %BasicBlock26 pushl %ebp pushl %eax addl $12, %ebp movl %esp, -28(%ebp) movl $LBB4_5, %eax

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

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() {

I think this is the same underlying issue as https://bugs.llvm.org/show_bug.cgi?id=40320. CCing Reid, who's had a bunch of thoughts on this in the past. On 1/11/20, 10:25 AM, "llvm-dev on behalf of Chrulski, Christopher M via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote: Hi, I've run into a bug with the LLVM

I think r262546 introduced the assumption that allocas are used exactly once with catchpad. It seems easy to fix, though. On Mon, Oct 17, 2016 at 11:51 PM, Carlo Kok via llvm-dev < llvm-dev at lists.llvm.org> wrote: > This turned out to be related to reusing the local used in the catchpad, > for example given the following c++ code: > > extern void rthrow(); > > int

Is this example what you had in mind? void f() { int *p = get_p(); use_p(p); try { may_throw(p); } catch (int) { // don't need p } use_p(p); } The idea is that because p is not modified or used within the catch region (the funclet), it can live in a callee-saved register across the whole function. That is true, it is possible, but I don't think it fits very well in

I think the simplest, most complete, short term fix, would be to call llvm::colorEHFunclets, and to have the relevant instrumentation passes apply the appropriate funclet bundle when inserting function calls. It's not elegant because it means every simple instrumentation pass that inserts regular function calls (ASan, TSan, MSan, instrprof, etc) needs to be funclet-aware. But, it will work,

I come across a situation that I am having a hard time to understand. When I compile the following code : char *tst( char *dest, const char *src, unsigned int len ) { for (int i=0 ; i<len ; i++) { dest[i] = src[i]; } return dest; } Clang generates this for the ‘for’ body: for.body: ; preds = %for.cond %arrayidx = getelementptr inbounds i8,

On Wed, Jul 1, 2015 at 2:10 PM, Joseph Tremoulet <jotrem at microsoft.com> wrote: > Hi, > > > > I'd be interested in an updated summary as well, especially any thoughts > you have on when the various pieces might come online and where extra hands > could be helpful; we're eager to build our EH support in LLILC on top of > this. > A preliminary step was

Is there any way to get it to delay this optimization where it goes from this: Initial selection DAG: BB#0 'bclr64:entry' SelectionDAG has 14 nodes: t0: ch = EntryToken t2: i64,ch = CopyFromReg t0, Register:i64 %vreg0 t4: i64,ch = CopyFromReg t0, Register:i64 %vreg1 t6: i64 = sub t4, Constant:i64<1> t7: i64 = shl Constant:i64<1>, t6

Setting the ISD::ROTL to Expand doesn't work? (via SetOperation) You could also do a Custom hook if that's what you're looking for. On Thu, Nov 3, 2016 at 5:12 PM, Phil Tomson <phil.a.tomson at gmail.com> wrote: > ... or perhaps to rephrase: > > In 3.9 it seems to be doing a smaller combine much sooner, whereas in 3.6 > it deferred that till later in the