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
Created attachment 434171 [details] File directives in LowLevelInterpreter.cpp.pre.s
Created attachment 434172 [details] File directives in LowLevelInterpreter.cpp.s
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
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.
Indeed, thanks for the investigation! Will work on a patch, but need to build a newer GCC first.
Created attachment 434423 [details] Patch
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?
(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.
Thank you for the patch, Angelos! This patch seems to fix the problem.
*** Bug 229491 has been marked as a duplicate of this bug. ***
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].
<rdar://problem/82530292>
(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.
I've disabled this feature for now via bug #229893. Please remember to revert that when fixing this bug!
(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?
(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?
(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.
(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.