SEH unwinding breaks in the presence of a jump-table on Windows/AArch64

[gabrielesvelto]

Bugzilla Link	41581
Version	8.0
OS	Windows NT
Blocks	#40566
CC	@efriedma-quic,@froydnj,@mstorsjo,@sylvestre

Extended Description

We encountered this issue when building Firefox for Windows/AArch64 using clang 8.0.0 [1]. The issue was introduced in [2].

What's happening is that we install an exception handler with SetUnhandledExceptionFilter() [3] to gather crash dumps. Starting with clang-8.0.0 this stopped working in many cases; when we encountered an exception Windows would be unable to unwind the stack and reach the exception handler, bailing out if it encountered a frame pointing to the JavaScript interpreter [3] on the stack. The interpreter uses macros to generate a large jump-table and [2] changed in which section the jump-table contents are stored. This seems to confuse Windows' unwinding machinery which simply bails out when encountering a frame that jumped through that table.

I've compared the code emitted w/ and w/o [2] applied and the only difference are the section directives around the jump table. I can attach the relevant assembly output if needed but it's very, very large.

I'm working on a reduced test-case and I'll attach it ASAP.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1542827
[2] 502c655
[3] https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/js/src/vm/Interpreter.cpp#1653-4424

[llvmbot]

Tom, we bisected this down to r352465/D57277. After that commit we can no longer unwind through xul!Interpret which is an enormous function that uses a jump table. Do you have any ideas offhand, and/or could you recommend what's the most useful information that Gabriele could provide from the repro?

[efriedma-quic]

I think all the unwinding patches got into 8.0, but if you have time, it would be nice to verify that the same issue shows up on trunk.

The most important thing here is probably preprocessed source code (produced with -E or -save-temps) and the command to build it. If the unwind information is wrong, it should probably be clear from the produced object file, even without a complete reproduction.

Looking over the code for emitting unwind tables, it looks like there's a bug where we silently emit bad unwind info for functions that are larger than 1MB... that seems very large for a single function, but maybe with a lot of jump tables it gets pushed over the limit?

[efriedma-quic]

Looked a little more; I think I've actually stumbled over the real issue. I'll try to post something soon.

[llvmbot]

Is this exposed by some recent code update in Firefox? The current unwind support is not complete.

[llvmbot]

Is this exposed by some recent code update in Firefox? The current unwind
support is not complete.

It started happening when we updated from clang 8.0.0rc3 to final, about a month ago.

[efriedma-quic]

Posted https://reviews.llvm.org/D61095

[efriedma-quic]

r359849.

[llvmbot]

Marking this for 8.0.1 since it was a regression introduced during the 8.0.0 release candidate timeline. The patch seems safe for a merge but let me know if you disagree.

[efriedma-quic]

My only concern with taking this in 8.0.1 is that it's possible someone is depending on clang emitting incorrect unwind tables instead of failing to compile in the cases that are not yet supported. But I think that's unlikely.

[RIscRIpt]

mentioned in issue llvm/llvm-bugzilla-archive#48088 (#47432)