WebKitGTK package hint: the -gdwarf64 option permits inclusion of full-size debugging symbols

[John Scott]

Hey,
This isn't really a bug so I'm just firing away into this inbox. I've been rebuilding the WebKitGTK source package with modifications on Trixie to suit my personal tastes and help debugging problems I have. In particular I use GCC/Binutils instead of Clang/LLVM and remove lines in debian/rules that change the compiler flags, like the following:
-# The debug packages produced by webkit are huge and cause problems in
-# most buildds. Use -g1 in all architectures to make them smaller.
-CFLAGS := $(CFLAGS:-g=-g1)
-CXXFLAGS := $(CXXFLAGS:-g=-g1)

and I set -DCMAKE_BUILD_TYPE=RelWithDebInfo. My intention here was to remove workarounds from debian/rules and see what breaks... and I'm pleased to say things mostly worked out. One hiccup I had was that, now that the debug symbols were no longer being slimmed down by -g1, I got a linker error:
> Use of -g for large project results in: relocation truncated to fit: R_X86_64_32 against `.debug_info'

After doing some digging and finding https://sourceware.org/bugzilla/show_bug.cgi?id=15444 I found this is a limitation of the old-school DWARF debug format not being able to handle such a massive amount of data. The DWARF64 format is an enhancement that solves this problem and it can be enabled with the -gdwarf64 option to GCC or Clang:
https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#index-gdwarf64
> If DWARF debugging information is enabled, the -gdwarf32 selects the 32-bit DWARF format and the -gdwarf64 selects the 64-bit DWARF format. The default is target specific, on most targets it is -gdwarf32 though.
> The 32-bit DWARF format is smaller, but can’t support more than 2GiB of debug information in any of the DWARF debug information sections. The 64-bit DWARF format allows larger debug information and might not be well supported by all consumers yet.
Indeed, for GCC in Trixie it does not do DWARF64 by default, so here it's opt-in.

The dwz tool, such as is used by dh_dwz, indeed can't handle the DWARF64 format (at least not with tooling in Trixie), so for my sake I've added an override. Dephelper >= 14 disables this sequence by default anyway and the Debhelper bug has interesting observations that this should have been done away with a long time ago... It might've exacerbated the buildd issues you recall seeing in the past. I'm not sure if dh_strip uses parallelism, but in case it does, using the appropriate environment variable or Debhelper option to run dh_strip serially can probably help.

The -gdwarf64 option merely tells GCC to use DWARF64 in preference to "DWARF32" when DWARF debugging information is included; thus, if -g is not used or debugging info would not otherwise be included, it does not cause it to be. The only downside is incompatibility with tools not supporting DWARF64 yet. Maybe, if it helps prevent build failures that happen only towards the very end, you'd like to add this pre-emptively just in case a compiler or WebKit update causes the debug symbols to exceed the size threshold, at least in Forky and newer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 411 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-webkit-maintainers/attachments/20260322/07ecbba3/attachment.sig>