1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-23 03:02:36 +01:00
llvm-mirror/test/CodeGen/AArch64/win-catchpad-nested-cxx.ll
Ten Tzen 60a9f85d44 [Windows EH] Fix the order of Nested try-catches in $tryMap$ table
This bug is exposed by Test7 of ehthrow.cxx in MSVC EH suite where
a rethrow occurs in a try-catch inside a catch (i.e., a nested Catch
handlers). See the test code in
https://github.com/microsoft/compiler-tests/blob/master/eh/ehthrow.cxx#L346

When an object is rethrown in a Catch handler, the copy-ctor of this
object must be executed after the destructions of live objects, but
BEFORE the dtors of live objects in parent handlers.

Today Windows 64-bit runtime (__CxxFrameHandler3 & 4) expects nested Catch
handers
are stored in pre-order (outer first, inner next) in $tryMap$ table, so
that given a State, its Catch's beginning State can be properly
retrieved. The Catch beginning state (which is also the ending State) is
the State where rethrown object's copy-ctor must take place.

LLVM currently stores nested catch handlers in post-ordering because
it's the natural way to compute the highest State in Catch.
The fix is to simply store TryCatch handler in pre-order, but update
Catch's highest State after child Catches are all processed.

Differential Revision: https://reviews.llvm.org/D79474?id=263919
2020-05-15 22:03:43 -07:00

101 lines
2.7 KiB
LLVM

; RUN: llc -verify-machineinstrs -mtriple=aarch64-pc-windows-msvc < %s \
; RUN: | FileCheck --check-prefix=CHECK %s
; Loosely based on IR for this C++ source code:
; void f(int p);
; void try_in_catch() {
; try {
; f(1);
; } catch (...) {
; try {
; f(2);
; } catch (...) {
; f(3);
; }
; }
; }
declare void @f(i32 %p)
declare i32 @__CxxFrameHandler3(...)
define i32 @try_in_catch() personality i32 (...)* @__CxxFrameHandler3 {
entry:
invoke void @f(i32 1)
to label %try.cont unwind label %catch.dispatch.1
try.cont:
ret i32 0
catch.dispatch.1:
%cs1 = catchswitch within none [label %handler1] unwind to caller
handler1:
%h1 = catchpad within %cs1 [i8* null, i32 64, i8* null]
invoke void @f(i32 2) [ "funclet"(token %h1) ]
to label %catchret1 unwind label %catch.dispatch.2
catchret1:
catchret from %h1 to label %try.cont
catch.dispatch.2:
%cs2 = catchswitch within %h1 [label %handler2] unwind to caller
handler2:
%h2 = catchpad within %cs2 [i8* null, i32 64, i8* null]
call void @f(i32 3)
catchret from %h2 to label %catchret1
}
; CHECK-LABEL: $cppxdata$try_in_catch:
; CHECK-NEXT: .word 429065506
; CHECK-NEXT: .word 4
; CHECK-NEXT: .word ($stateUnwindMap$try_in_catch)
; CHECK-NEXT: .word 2
; CHECK-NEXT: .word ($tryMap$try_in_catch)
; ip2state num + ptr
; CHECK-NEXT: .word 7
; CHECK-NEXT: .word ($ip2state$try_in_catch)
; unwindhelp offset
; CHECK-NEXT: .word -16
; CHECK-NEXT: .word 0
; EHFlags
; CHECK-NEXT: .word 1
; CHECK-LABEL: $tryMap$try_in_catch:
; CHECK-NEXT: .word 0
; CHECK-NEXT: .word 0
; CHECK-NEXT: .word 3
; CHECK-NEXT: .word 1
; CHECK-NEXT: .word ($handlerMap$0$try_in_catch)
; CHECK-NEXT: .word 2
; CHECK-NEXT: .word 2
; CHECK-NEXT: .word 3
; CHECK-NEXT: .word 1
; CHECK-NEXT: .word ($handlerMap$1$try_in_catch)
; CHECK: $handlerMap$0$try_in_catch:
; CHECK-NEXT: .word 64
; CHECK-NEXT: .word 0
; CHECK-NEXT: .word 0
; CHECK-NEXT: .word "?catch${{[0-9]+}}@?0?try_in_catch@4HA"
; CHECK-NEXT: .word 0
; CHECK: $handlerMap$1$try_in_catch:
; CHECK-NEXT: .word 64
; CHECK-NEXT: .word 0
; CHECK-NEXT: .word 0
; CHECK-NEXT: .word "?catch${{[0-9]+}}@?0?try_in_catch@4HA"
; CHECK-NEXT: .word 0
; CHECK: $ip2state$try_in_catch:
; CHECK-NEXT: .word .Lfunc_begin0@IMGREL
; CHECK-NEXT: .word -1
; CHECK-NEXT: .word .Ltmp0@IMGREL
; CHECK-NEXT: .word 0
; CHECK-NEXT: .word .Ltmp1@IMGREL
; CHECK-NEXT: .word -1
; CHECK-NEXT: .word "?catch$2@?0?try_in_catch@4HA"@IMGREL
; CHECK-NEXT: .word 1
; CHECK-NEXT: .word .Ltmp2@IMGREL
; CHECK-NEXT: .word 2
; CHECK-NEXT: .word .Ltmp3@IMGREL
; CHECK-NEXT: .word 1
; CHECK-NEXT: .word "?catch$4@?0?try_in_catch@4HA"@IMGREL
; CHECK-NEXT: .word 3