https://bugs.llvm.org/show_bug.cgi?id=36247
Bug ID: 36247
Summary: [WinEH] Inline assembly corrupts catch handler
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: smee...@fb.com
CC: compn...@compnerd.org, david.majne...@gmail.com,
llvm-bugs@lists.llvm.org, r...@google.com
Created attachment 19814
--> https://bugs.llvm.org/attachment.cgi?id=19814&action=edit
IR
% cat exc.cpp
void f();
int main() {
try {
f();
} catch (int) {
__asm__ ("nop");
return 0;
}
return 1;
}
% clang -target i686-windows-msvc -S -o - exc.cpp
...
"?catch$1@?0?main@4HA":
LBB0_1: # %catch
pushl %ebp
addl $12, %ebp
movl %esp, -28(%ebp)
Lfunc_end0:
.section .xdata,"dr"
.p2align 2
L__ehtable$main:
.long 429065506 # MagicNumber
...
Note that the EH table is emitted in the middle of the catch handler's code
(right after its prologue), which is obviously bogus. Slightly cleaned up IR
generated from the C++ source above is attached for convenience. Removing the
`call void asm` from the IR makes llc generate sane assembly for the catch
handler.
The same occurs for x86-64, but MS doesn't officially support inline assembly
for x86-64, so I presume we don't care too much. To be perfectly honest, I
don't care very much about the x86 case either, since I have a trivial local
workaround; I'm just reporting it for completeness.
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
