Bug 279360 – REGRESSION(282934@main): Breaks debugedit when built with GCC

• Status: RESOLVED
• Resolution: FIXED
• Component: WPE WebKit

[Michael Catanzaro]

Revert 282934@main because Breaks debugedit on ppc64le.

[Michael Catanzaro]

Pull request: https://github.com/WebKit/WebKit/pull/33321

[Michael Catanzaro]

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.

[Michael Catanzaro]

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

[Michael Catanzaro]

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.

[Michael Catanzaro]

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.

[Michael Catanzaro]

(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.

[Michael Catanzaro]

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.

[Michael Catanzaro]

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!)

[Nikolas Zimmermann]

I am using this flag successfully with gcc, not clang using cross-toolchain-helper to build for rpi4.

[Michael Catanzaro]

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.)

[Adrian Perez]

(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.

[Michael Catanzaro]

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.

[Michael Catanzaro]

(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.

[Michael Catanzaro]

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.

[EWS]

Committed 283843@main (5a287cdc5ab4): <https://commits.webkit.org/283843@main>

Reviewed commits have been landed. Closing PR #33321 and removing active labels.