1801322 - Missing unwind information for delayed imports in Windows x64 builds' xul.dll

Status: RESOLVED DUPLICATE of bug 1789713

(Firefox Build System :: General, defect)

Description

[Yannis Juglaret [:yannis]]

Attachment: Output of unwindchecker for Firefox 107.0 Release

Windows x64 executable files embed stack unwinding information. Missing stack unwinding information can lead to various problems, including incomplete stacks in debuggers or crash reports, incomplete profiler data, and failures to call structured exception handlers. They can currently prevent our crash reporter from being even called to generate a crash report (see for example bug 1800898), although a separate not-filed-yet bug will try to make our crash reporter survive to stack unwinding failures.

I provide a tool that can be used to track code that makes calls but doesn't have associated stack unwinding information. In this specific bug I would like to focus on code that originates from delay-loaded DLLs in xul.dll.

When compiling a standalone executable with a delay-loaded DLL in Visual Studio, delay-load code like shown below gets added and the __tailMerge_XXXX_dll code has associated stack unwinding information.

                             __imp_load_MessageBoxW
                             DelayLoad_MessageBoxW
       LEA        RAX,[ImgDelayDescr_IAT]
       JMP        __tailMerge_user32_dll

                             __tailMerge_user32_dll
...
       MOV        RDX,RAX
       LEA        RCX,[ImgDelayDescr]
       CALL       __delayLoadHelper2
       MOVDQA     XMM0,xmmword ptr [RSP + 0x20]
       MOVDQA     XMM1,xmmword ptr [RSP + 0x30]
       MOVDQA     XMM2,xmmword ptr [RSP + 0x40]
...

In Firefox's xul.dll, we get similar code to handle each delayed import. However in our case the __tailMerge_XXXX_dll code does not seem to have associated unwind information. I would like to know whether this is intentional, and whether it can be fixed?

Please find attached the output from the tool when run on Firefox 107.0 Release's xul.dll. You will see a lot of entries that look like this:

0x1852c3649:	e832e4d7fc	call	0x182041a80
0x1852c364e:	660f6f0424	movdqa	xmm0, xmmword ptr [rsp]
0x1852c3653:	660f6f4c2410	movdqa	xmm1, xmmword ptr [rsp + 0x10]
0x1852c3659:	660f6f542420	movdqa	xmm2, xmmword ptr [rsp + 0x20]

These are the entries I'd like to focus on with this bug, and they should disappear from the output if the problem is fixed. The tool can thus be used to assess success in fixing this.

Thank you!

Comment 1

[Bob Owen (:bobowen)]

Just a note to add that this issue prevented me from getting a crash dump for a test failure in bug 1793972.
This was a particular problem there because I could only reproduce the issue on the try test runs.

Comment 2

[Gian-Carlo Pascutto [:gcp]]

Mike, do we understand correctly this is likely a bug in Clang/LLVM?

Comment 3

[Mike Hommey [:glandium]]

Sounds like this would be a bug in lld-link.exe. One way to make sure of it would be to relink xul.dll with MSVC link.exe's.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

I filed bug 1789713 about this as well.