Bug 228267 – resolve-asm-file-conflicts.rb build failure after upgrade to CMake 3.21.0; DWARF 5 incompatibility

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Adrian Vovk]

Created attachment 434170 [details]
BuildStream log of the failing build

After upgrading to CMake 3.21.0, WebKitGTK would fail to build. I've attached the full build log. Here's the important error message:

> Source/JavaScriptCore/CMakeFiles/LowLevelInterpreterLib.dir/llint/LowLevelInterpreter.cpp.s:109399: Error: file table slot 1 is already occupied by a different file (/buildstream/carbonOS/pkgs/webkitgtk.bst/Source/JavaScriptCore/llint/LowLevelInterpreter.cpp vs /buildstream/carbonOS/pkgs/webkitgtk.bst/_builddir//buildstream/carbonOS/pkgs/webkitgtk.bst/Source/JavaScriptCore/llint/LowLevelInterpreter.cpp)
This is a symptom of resolve-asm-file-conflict's incompatibility with DWARF 5



I followed this bug down through the stack and I think I have a pretty solid understanding of what happened to cause it:

- CMake 3.21.0 switched from relative to absolute paths for the Ninja generator [1]. This means that GCC started encoding all of its `.file` directives as absolute paths
- To comply with DWARF 5 [2], GCC was updated [3] to emit a `.file` directive with a number of 0, the path to the current working directory, and the path to the source file. The working directory is emitted even if the source file path is absolute
- resolve-asm-file-conflicts.rb concatenates the CWD and the source path together to get "/path/to/builddir//path/to/source". This causes it to misbehave
- The same script renumbers the DWARF 5 `.file 0` directive and makes it match the rest of the file directives. This leads to a situation where the generated assembly has two `.file 1` directives with the same source path; however, one has a CWD and the other does not have a CWD.
- `as` cannot handle two .file directives with the same number where one has a CWD and the other doesn't. Also, by changing the file number from 0, the script breaks the DWARF 5 format


To fix this, resolve-asm-file-conflicts.rb should detect a `.file 0` directive and ensure that it is left unchanged. To test this fix, I edited the generated LowLevelInterpreter.cpp.s to renumber the DWARF 5 directive back to 0. That allowed `as` to build the file

I've attached the .file directives of LowLevelInterpreter.cpp.pre.s and LowLevelInterpreter.cpp.s

[1]: https://gitlab.kitware.com/cmake/cmake/-/commit/c564a3e3fff52ef811291c5ba8fb07a5a1b47f97
[2]: https://sourceware.org/bugzilla/show_bug.cgi?id=25614#c9
[3]: https://github.com/gcc-mirror/gcc/commit/3a9e6ee42acf1e3d00e4391ab1b1a56bb0b32ad2

[Adrian Vovk]

Created attachment 434171 [details]
File directives in LowLevelInterpreter.cpp.pre.s

[Adrian Vovk]

Created attachment 434172 [details]
File directives in LowLevelInterpreter.cpp.s

[Adrian Vovk]

Created attachment 434173 [details]
The arguments passed into postprocess-asm in cmake 3.21.0 vs 3.20.5

I put this here just in case it's useful. As you can see cmake 3.21.0 uses absolute paths and cmake 3.20.5 uses relative paths

[Adrian Perez]

Thanks a lot for the thorough bug report and for doing the initial
troubleshooting—much appreciated.

We had not seen this ourselves probably because the Flatpak SDK we
use for developing does not always have the latest CMake version; but
we definitely need to fix this.

[Angelos Oikonomopoulos]

Indeed, thanks for the investigation! Will work on a patch, but need to build a newer GCC first.

[Angelos Oikonomopoulos]

Created attachment 434423 [details]
Patch

[Angelos Oikonomopoulos]

Unfortunately, I haven't been able to reproduce the issue with cmake 3.21.0 and GCC 11.1.0 (with --debug, so the asm postprocessing was enabled).

Adrian, could you test if the patch I just uploaded fixes things for you?

[Angelos Oikonomopoulos]

(In reply to Angelos Oikonomopoulos from comment #7)

> Adrian, could you test if the patch I just uploaded fixes things for you?

Meaning Adrian Vovk, of course.

[Adrian Vovk]

Thank you for the patch, Angelos! This patch seems to fix the problem.

[Michael Catanzaro]

*** Bug 229491 has been marked as a duplicate of this bug. ***

[EWS]

Committed r281758 (241100@main): <https://commits.webkit.org/241100@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 434423 [details].

[Radar WebKit Bug Importer]

<rdar://problem/82530292>

[Michael Catanzaro]

(In reply to Adrian Vovk from comment #0)
> > Source/JavaScriptCore/CMakeFiles/LowLevelInterpreterLib.dir/llint/LowLevelInterpreter.cpp.s:109399: Error: file table slot 1 is already occupied by a different file (/buildstream/carbonOS/pkgs/webkitgtk.bst/Source/JavaScriptCore/llint/LowLevelInterpreter.cpp vs /buildstream/carbonOS/pkgs/webkitgtk.bst/_builddir//buildstream/carbonOS/pkgs/webkitgtk.bst/Source/JavaScriptCore/llint/LowLevelInterpreter.cpp)
> This is a symptom of resolve-asm-file-conflict's incompatibility with DWARF 5

I'm still seeing this exact same error even though this has landed:

/tmp/ccHybVZr.s: Assembler messages:
/tmp/ccHybVZr.s:23: Error: file table slot 1 is already occupied by a different file (../../Source/JavaScriptCore/llint/LowLevelInterpreter.cpp vs /home/mcatanzaro/Projects/WebKit/Source/JavaScriptCore/llint/LowLevelInterpreter.asm)
/tmp/ccHybVZr.s:103670: Error: file table slot 2 is already occupied by a different file (/home/mcatanzaro/Projects/WebKit/WebKitBuild/GNOME/JavaScriptCore/DerivedSources/InitBytecodes.asm vs ../../Source/JavaScriptCore/heap/SlotVisitorInlines.h)
/tmp/ccHybVZr.s:103689: Error: file table slot 3 is already occupied by a different file (/home/mcatanzaro/Projects/WebKit/Source/JavaScriptCore/llint/LowLevelInterpreter64.asm vs WTF/Headers/wtf/Atomics.h)
/tmp/ccHybVZr.s:103697: Error: file table slot 4 is already occupied by a different file (/home/mcatanzaro/Projects/WebKit/Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm vs ../../Source/JavaScriptCore/heap/HeapCellInlines.h)
/tmp/ccHybVZr.s:103702: Error: file table slot 5 is already occupied by a different file (/home/mcatanzaro/Projects/WebKit/WebKitBuild/GNOME/JavaScriptCore/DerivedSources/InitWasm.asm vs ../../Source/JavaScriptCore/heap/PreciseAllocation.h)
/tmp/ccHybVZr.s:103728: Error: file table slot 6 is already occupied by a different file (/home/mcatanzaro/Projects/WebKit/Source/JavaScriptCore/llint/WebAssembly.asm vs ../../Source/JavaScriptCore/heap/MarkedBlock.h)

Reopening.

[Michael Catanzaro]

I've disabled this feature for now via bug #229893. Please remember to revert that when fixing this bug!

[Angelos Oikonomopoulos]

(In reply to Michael Catanzaro from comment #13)
> (In reply to Adrian Vovk from comment #0)
> > > Source/JavaScriptCore/CMakeFiles/LowLevelInterpreterLib.dir/llint/LowLevelInterpreter.cpp.s:109399: Error: file table slot 1 is already occupied by a different file (/buildstream/carbonOS/pkgs/webkitgtk.bst/Source/JavaScriptCore/llint/LowLevelInterpreter.cpp vs /buildstream/carbonOS/pkgs/webkitgtk.bst/_builddir//buildstream/carbonOS/pkgs/webkitgtk.bst/Source/JavaScriptCore/llint/LowLevelInterpreter.cpp)
> > This is a symptom of resolve-asm-file-conflict's incompatibility with DWARF 5
> 
> I'm still seeing this exact same error even though this has landed:
> 
> /tmp/ccHybVZr.s: Assembler messages:
> /tmp/ccHybVZr.s:23: Error: file table slot 1 is already occupied by a
> different file (../../Source/JavaScriptCore/llint/LowLevelInterpreter.cpp vs
> /home/mcatanzaro/Projects/WebKit/Source/JavaScriptCore/llint/
> LowLevelInterpreter.asm)
> /tmp/ccHybVZr.s:103670: Error: file table slot 2 is already occupied by a
> different file
> (/home/mcatanzaro/Projects/WebKit/WebKitBuild/GNOME/JavaScriptCore/
> DerivedSources/InitBytecodes.asm vs
> ../../Source/JavaScriptCore/heap/SlotVisitorInlines.h)
> /tmp/ccHybVZr.s:103689: Error: file table slot 3 is already occupied by a
> different file
> (/home/mcatanzaro/Projects/WebKit/Source/JavaScriptCore/llint/
> LowLevelInterpreter64.asm vs WTF/Headers/wtf/Atomics.h)
> /tmp/ccHybVZr.s:103697: Error: file table slot 4 is already occupied by a
> different file
> (/home/mcatanzaro/Projects/WebKit/Source/JavaScriptCore/llint/
> LowLevelInterpreter32_64.asm vs
> ../../Source/JavaScriptCore/heap/HeapCellInlines.h)
> /tmp/ccHybVZr.s:103702: Error: file table slot 5 is already occupied by a
> different file
> (/home/mcatanzaro/Projects/WebKit/WebKitBuild/GNOME/JavaScriptCore/
> DerivedSources/InitWasm.asm vs
> ../../Source/JavaScriptCore/heap/PreciseAllocation.h)
> /tmp/ccHybVZr.s:103728: Error: file table slot 6 is already occupied by a
> different file
> (/home/mcatanzaro/Projects/WebKit/Source/JavaScriptCore/llint/WebAssembly.
> asm vs ../../Source/JavaScriptCore/heap/MarkedBlock.h)
> 
> Reopening.

Ouch. Any hints on where I should try to reproduce this?

[Michael Catanzaro]

(In reply to Angelos Oikonomopoulos from comment #15)
> Ouch. Any hints on where I should try to reproduce this?

Try building in an F34 toolbox?

[Angelos Oikonomopoulos]

(In reply to Michael Catanzaro from comment #16)
> (In reply to Angelos Oikonomopoulos from comment #15)
> > Ouch. Any hints on where I should try to reproduce this?
> 
> Try building in an F34 toolbox?

Thanks. Unfortunately, building with

./Tools/Scripts/build-jsc --jsc-only --debug --cmakeargs=-DGCC_OFFLINEASM_SOURCE_MAP=ON

(which gives the -- Enabling asm postprocessing message) fails to reproduce the issue in the official fedora:34 docker image. For reference:

-- The CXX compiler identification is GNU 11.2.1

And gcc -v reports: gcc version 11.2.1 20210728 (Red Hat 11.2.1-1) (GCC).

If there's anything special about your setup that I'm missing, any tips would be welcome.

[Michael Catanzaro]

(In reply to Angelos Oikonomopoulos from comment #17)
> If there's anything special about your setup that I'm missing, any tips
> would be welcome.

Well I'll be, seems it's only broken when built with -flto=auto. Let me close this and open a new bug.