[llvm-bugs] [Bug 45163] New: clang-cl.exe try/catch wrong asm

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Mar 10 06:56:17 PDT 2020


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

            Bug ID: 45163
           Summary: clang-cl.exe try/catch wrong asm
           Product: clang
           Version: 9.0
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: Danczyk_Josh_R at cat.com
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

I have tried to recreate this bug with a simple example, but the compiler
outsmarts me at every turn. Instead I'll describe what I think is going on.
This is x64 on Windows 10 using clang-cl.exe

Consider this pseudo-code:
void f() {
  do_something_that_involves_a_lot_of_xmm_registers;
  try {
    some_other_function();
  } catch (const SomeExceptionType& e) {
    handle_exception;
  }
}

The prologue of f() pushes a number of registers to stack. It also specifically
writes xmm6 to the stack, which as I read from the Microsoft ABI is
non-volatile. The epilogue of f() pops everything and restore xmm6. Everything
looks fine. 

Now the problem. When some_other_function() throws SomeExceptionType the
exception handler is invoked and after several calls we end up in the catch
statement -- as a function. Something like
f()->some_other_function()->exception_handler()->catch_statement(). The
prologue of this catch statement "function" is a carbon copy of f()'s prologue,
meaning we push all the registers and store xmm6 to the stack -- even though
these registers are not used. But we store to the *exact memory location* that
f() originally stored. Since xmm6 was damaged during
do_something_that_involves_a_lot_of_xmm_registers the damaged value is written.
Then when we leave f() we restore the damaged xmm6, leaving f()'s caller in a
broken state.

I "solved" the issue by placing the try/catch in a [[gnu::noinline]] function.
This works because this code doesn't directly do any floating point and
therefore doesn't need to save/restore xmm6.

-- 
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/20200310/66198061/attachment-0001.html>


More information about the llvm-bugs mailing list