OSDN Git Service

[Windows EH] Fix the order of Nested try-catches in $tryMap$ table
authorTen Tzen <tentzen@microsoft.com>
Sat, 16 May 2020 05:03:43 +0000 (22:03 -0700)
committerTen Tzen <tentzen@microsoft.com>
Sat, 16 May 2020 05:03:43 +0000 (22:03 -0700)
commite32f8e5d4ae88c2934f310f3f8a762f969bc6793
tree939a467dcfa21c86e607ec438a80475e9008f4e2
parent945ad141ce63c94b5822d52ad76c49aba906a4b8
[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
llvm/lib/CodeGen/WinEHPrepare.cpp
llvm/test/CodeGen/AArch64/win-catchpad-nested-cxx.ll [new file with mode: 0644]
llvm/test/CodeGen/X86/win-catchpad-nested-cxx.ll