[llvm-bugs] [Bug 44174] New: A range of ScopeRecord does not match the code enclosed by __try

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=44174

            Bug ID: 44174
           Summary: A range of ScopeRecord does not match the code
                    enclosed by __try
           Product: clang
           Version: 9.0
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: leamovret at gmail.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org,
                    neeilans at live.com, richard-llvm at metafoo.co.uk

A range of ScopeRecord does not match the code enclosed by __try

I hit a potential bug that clang generates a wrong Windows SEH structure.

Here's an NMAKE project to reproduce the issue.
https://github.com/msmania/seh-debug/tree/191128-report-to-llvm

My build environment consists of:

- Clang 9.0 x86_64-pc-windows-msvc
  (downloaded from http://releases.llvm.org/download.html)
- Visual Studio 2019 Community
- Windows 10 SDK 10.0.18362.0

To build, you open "x64 Native Tools Command Prompt for VS 2019" and run NMAKE.
 You may need to update `Makefile` to adjust installation paths such as
$(MSVCDIR), $(WIN10KITINCLUDE), or $(CLANG).

This Makefile builds src/main.cpp with two compilers clang++ and MSVC. An
executable will be generated as bin-clang/amd64/t.exe and bin/amd64/t.exe
respectively.

These executables run without any crash, but embedded SEH information in
clang's output looks not correct, especially translation from `__try` block
into a range of ScopeTable's record.  MSVC's output looks correct on the other
hand.  This will cause a second chance exception even from __try block.

For example, let's think about this code.

  __try {
    CoInitialize(nullptr);
  }
  __except (ExceptionFilter(GetExceptionInformation())) {
    __debugbreak();
  }

It's compiled like this.  Analyzing SEH info in the binary, the first xor,
setting the first argument to 0, is not included in the ScopeRecord.

   77 00007ff7`64dc1153 31c9            xor     ecx,ecx
   77 00007ff7`64dc1155 ff1555270000    call    qword ptr
       [t!_imp_CoInitialize (00007ff7`64dc38b0)]

This case should be ok because `xor ecx,ecx` will never throw an exception, but
in a more complex scenario, incorrect ScopeRecord will cause an unexpected
behavior.

More examples and detailed explanations are available in the links below:

Clang:
https://github.com/msmania/seh-debug/blob/191128-report-to-llvm/seh-clang.md

MSVC:
https://github.com/msmania/seh-debug/blob/191128-report-to-llvm/seh-msvc.md

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191128/5c6a9ec4/attachment-0001.html>