279360 2024-09-09 07:03:51 -0700 REGRESSION(282934@main): Breaks debugedit when built with GCC 2024-09-18 08:07:03 -0700 1 1 1 Unclassified WebKit WPE WebKit WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED https://bugzilla.redhat.com/show_bug.cgi?id=2310828 P2 Normal --- 278861 1 mcatanzaro mcatanzaro aperez bugs-noreply mcatanzaro webkit-bug-importer zimmermann oldest_to_newest 2058611 0 mcatanzaro 2024-09-09 07:03:51 -0700 Revert 282934@main because Breaks debugedit on ppc64le. 2058613 1 mcatanzaro 2024-09-09 07:05:24 -0700 Pull request: https://github.com/WebKit/WebKit/pull/33321 2058614 2 mcatanzaro 2024-09-09 07:08:27 -0700 So the problem here is "failures when processing webkitgtk binary files with DW_UT_type" https://bugzilla.redhat.com/show_bug.cgi?id=2310828 I've created a pull request to revert, but the downstream bug is pretty active right now, so let's wait and see. I don't understand the bug and it's not yet clear to me whether WebKit is wrong to add this flag or whether this is a toolchain issue. 2058615 3 mcatanzaro 2024-09-09 07:10:38 -0700 As we wait for more replies from toolchain developers, I guess the two most likely options here are: * Use this flag only for aarch64 debug builds, where it's needed due to bug #278861 * Use this flag everywhere except ppc64le 2058616 4 mcatanzaro 2024-09-09 07:15:11 -0700 Looking at gcc(1) I see there is a prominent warning that this flag is not compatible with "all DWARF consumers" so maybe we should use it only in developer mode: -fdebug-types-section When using DWARF Version 4 or higher, type DIEs can be put into their own ".debug_types" section instead of making them part of the ".debug_info" section. It is more efficient to put them in a separate comdat section since the linker can then remove duplicates. But not all DWARF consumers support ".debug_types" sections yet and on some objects ".debug_types" produces larger instead of smaller debugging information. 2058622 5 mcatanzaro 2024-09-09 08:28:18 -0700 There is some interesting discussion in the downstream bug. I still don't understand why the build only fails on ppc64le. I understand that using -fdebug-types-section is incompatible with dwz, which is what distros use to optimize debuginfo. I get the impression that we shouldn't use this flag unless we have to, but this also looks like a case where we have to. 2058946 6 mcatanzaro 2024-09-10 06:16:36 -0700 (In reply to Michael Catanzaro from comment #5) > There is some interesting discussion in the downstream bug. I still don't > understand why the build only fails on ppc64le. It's because I use Clang when building for all other architectures. But Clang just crashes on ppc64le, so I use GCC there. -fdebug-types-section breaks only when using GCC. 2058968 7 mcatanzaro 2024-09-10 07:30:40 -0700 At this point, I think the problem is this flag is going to break any distro builds regardless of architecture when using GCC. I am going to verify that by building for aarch64 with GCC now. If so, conditionalizing on architecture is not an appropriate solution. But this flag seems to work fine with Clang. The reason I noticed trouble only with ppc64le is I switched Fedora to build with Clang, except for ppc64le where Clang crashes. 2059039 8 mcatanzaro 2024-09-10 11:11:39 -0700 Dan has verified this change does break Fedora aarch64 builds if we use GCC rather than Clang. So let's try using -fdebug-types-section only when building with Clang. (I'm not actually sure why this doesn't break when Clang is used!) 2059057 9 zimmermann 2024-09-10 12:19:38 -0700 I am using this flag successfully with gcc, not clang using cross-toolchain-helper to build for rpi4. 2059115 10 mcatanzaro 2024-09-10 16:16:24 -0700 OK, drat. Next idea: use the flag only for WPE but not for GTK? (Because GTK surely needs to prioritize distro builds above any other considerations.) Or: use the flag only in DEVELOPER_MODE? (Because debugedit and dwz won't be a problem there.) 2059230 11 aperez 2024-09-11 01:10:04 -0700 (In reply to Michael Catanzaro from comment #5) > There is some interesting discussion in the downstream bug. I still don't > understand why the build only fails on ppc64le. I understand that using > -fdebug-types-section is incompatible with dwz, which is what distros use to > optimize debuginfo. > > I get the impression that we shouldn't use this flag unless we have to, but > this also looks like a case where we have to. I was under the impression that most distros would pass -gz[=zlib] (equivalent to --compress-debug-sections=zlib) to the compiler and linker command lines whenever they wanted compressed debuginfo, instead of relying on an external tool (dwz) that is likely to lag behind feature-wise. Not only that: the fact is that "objcopy --[de]compress-debug-sections" exists! Conversely, for splitting debug information one would pass -gsplit-dwarf to the compiler/linker, and there are objcopy incantations to extract split debuginfo from binaries. Binutils has supported compressed debug info in current (modern) formats since ~2015, and Clang since a bit earlier IIRC. 2059321 12 mcatanzaro 2024-09-11 09:36:51 -0700 I've checked Fedora ecosystem (https://src.fedoraproject.org/rpms/redhat-rpm-config//blob/rawhide/f/buildflags.md) and freedesktop-sdk ecosystem (https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/master/include/flags.yml?ref_type=heads and https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/master/files/stripper/main.cpp#L501). They're using dwz and debugedit, not following your suggestions. Not sure what other distros do. 2059520 13 mcatanzaro 2024-09-11 18:22:57 -0700 (In reply to Michael Catanzaro from comment #10) > Next idea: use the flag only for WPE but not for GTK? (Because GTK surely > needs to prioritize distro builds above any other considerations.) > > Or: use the flag only in DEVELOPER_MODE? (Because debugedit and dwz won't be > a problem there.) Any preferences? Neither of these choices really make much sense, but we have to pick something. 2059750 14 mcatanzaro 2024-09-12 13:08:17 -0700 I'm still not sure what to do here, so I'll just go with DEVELOPER_MODE for now. Feel free to change this to something else as long as it doesn't break WebKitGTK for distros. 2061072 15 ews-feeder 2024-09-18 08:07:00 -0700 Committed 283843@main (5a287cdc5ab4): <https://commits.webkit.org/283843@main> Reviewed commits have been landed. Closing PR #33321 and removing active labels.