[Webkit-unassigned] [Bug 228267] New: resolve-asm-file-conflicts.rb build failure after upgrade to CMake 3.21.0; DWARF 5 incompatibility

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=228267

            Bug ID: 228267
           Summary: resolve-asm-file-conflicts.rb build failure after
                    upgrade to CMake 3.21.0; DWARF 5 incompatibility
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: adrianvovk at gmail.com

Created attachment 434170

  --> https://bugs.webkit.org/attachment.cgi?id=434170&action=review

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210724/41b5bf0b/attachment.htm>