cmd/compile: consider using DWARF 5

[aclements]

DWARF 5 has several advantages over previous versions of DWARF. Notably,

1. It supports position-independent representations, which significantly reduces the number of relocations in object files and hence the size of object files and the load on the linker. In the go binary, 49% of the 503,361 total relocations are in the DWARF.

2. It supports much more compact location and range list formats. The location and range list sections are 6% of the 12MiB of the go binary, even when zlib compressed.

3. It has an official language code for Go. :)

DWARF 5 is quite new, and I don't think the rest of the ecosystem is ready yet, but I wanted to get the idea floating. It is supported by the GNU and LLVM toolchains and some debuggers. Support was added in GCC 7.1 (May 2017) and GDB 8.0 (June 2017). It appears to be in the latest LLVM, which covers most of the Xcode tools, though I can't find when it was added.

It is currently not supported by LLDB or the macOS linker. We could potentially get around the macOS linker by leaving out the Go DWARF from the objects we pass to the system linker and then merging it in to the final binary (we already do a merge step). This is more feasible with DWARF5 because it's mostly position-independent, so we wouldn't need dsymutil to relocate it for us.

/cc @cherrymui @heschik @dr2chase @randall77 @ianlancetaylor

[heschi]

Strongly in favor of doing this the moment we think we can get away with it. I'm happy to do the work for location lists.

[bradfitz]

Un-proposaling this per discussion with @ianlancetaylor.

[aarzilli]

For reference, the debug info for the linux_amd64/go1.11.1 version of cmd/compile is 15MB of which 8MB are in debug_loc and debug_ranges, specifically:

total size 20752567

section             compressed    uncompressed
.zdebug_abbrev             274 B         467 B
.zdebug_line            739610 B     1931456 B
.zdebug_frame           158093 B      559020 B
.zdebug_pubnames         38451 B      251078 B
.zdebug_pubtypes         45270 B      211390 B
.debug_gdb_scripts                        42 B
.zdebug_info           1257828 B     3694829 B
.zdebug_loc             989048 B     5914085 B
.zdebug_ranges          442419 B     2461408 B

Rewriting debug_loc and debug_ranges in the new format specified by DWARF 5 will reduce the size of debug_ranges to 774460 B (31% of DWARF 4 size) and of debug_loc to 2032960 B (34% of DWARF 4 size).

Edit: debug_ranges and debug_loc were accidentally swapped in the last sentence.

[dr2chase]

Is compression still doing a better job at reducing binary size than DWARF 5, or can D5 also be compressed? I did just mostly finish a DWARF splitter for OSX that recreates the expected file in the expected place, and adds the expected UUID for matching the two files. I suspect I ought to be using a hash of the binary contents excluding debugging information, so that identical files will remain identical after UUIDs are added.

[aclements]

The compression isn't actually part of the DWARF spec, so it's orthogonal to the DWARF version and can be used with DWARF 5.

@aarzilli, thanks for doing that experiment. Can you get the numbers for DWARF 5 if it's also zlib compressed?

[aarzilli]

@aarzilli, thanks for doing that experiment. Can you get the numbers for DWARF 5 if it's also zlib compressed?

After compression the size is basically the same, 98% (of compressed DWARF4) for debug_ranges and 77% (of compressed DWARF4) for debug_loc. The compression time however is reduced by 40%.

[dr2chase]

Is that compression time+space comparing current low-effort (higher speed) versus future low-effort? Sorry to be so picky, it's just that we've made mistakes here before.

[aarzilli]

I'm comparing compression using zlib.BestSpeed for both, like the linker. Since measuring how much time it actually took inside the linker is hard I measured how much time it takes to recompress the compressed section.

Because I have send the whole section to the compressor and the linker doesn't, I get slightly better compression than the linker. But the difference is small (around 1%) and since I'm doing it for both DWARF 4 and DWARF 5 the result should be valid.

[joeyjiaojg]

Parsed a DWARF5 linux kernel module, the below statement of index 0 is not nil. It returns the real file path.

<html>
<body>
<!--StartFragment-->

// Files returns the file name table of this compilation unit as of
--
  | // the current position in the line table. The file name table may be
  | // referenced from attributes in this compilation unit such as
  | // AttrDeclFile.
  | //
  **| // Entry 0 is always nil, since file index 0 represents "no file".**
  | //
  | // The file name table of a compilation unit is not fixed. Files
  | // returns the file table as of the current position in the line
  | // table. This may contain more entries than the file table at an
  | // earlier position in the line table, though existing entries never
  | // change.
  | func (r *LineReader) Files() []*LineFile {
  | return r.fileEntries
  | }

<!--EndFragment-->
</body>
</html>

[mdempsky]

FWIW, GCC 11.1 was released on April 27, 2021. From https://gcc.gnu.org/gcc-11/changes.html:

For targets that produce DWARF debugging information GCC now defaults to DWARF version 5 (with the exception of VxWorks and Darwin/Mac OS X which default to version 2 and AIX which defaults to version 4).

Also, Clang 14 was released on March 25, 2022. From https://releases.llvm.org/14.0.0/tools/clang/docs/ReleaseNotes.html#dwarf-support-in-clang:

The default DWARF version has increased from DWARFv4 to DWARFv5. You can opt back in to the old behavior with -gdwarf-4 or -fdebug-default-version=4. Some platforms (Darwin, Android, and SCE for instance) already opt out of this version bump as is suitable for the platform

[thanm]

Hi all, I'm working on a set of patches to switch the Go compiler/linker over to DWARF 5, just FYI.

[gopherbot]

Change https://go.dev/cl/633878 mentions this issue: cmdinternal/dwarf: add DW_LNCT and DW_UT constant definitions

[gopherbot]

Change https://go.dev/cl/633880 mentions this issue: cmd/internal/objabi: add new R_DWTXTADDR_* relocation types

[gopherbot]

Change https://go.dev/cl/635345 mentions this issue: cmd/compile,cmd/link: move to DWARF5-style range lists

[gopherbot]

Change https://go.dev/cl/635337 mentions this issue: cmd: initial compiler+linker support for DWARF5 .debug_addr

[gopherbot]

Change https://go.dev/cl/633879 mentions this issue: cmd/link, cmd/internal/dwarf: add DWARF5 line table support

[gopherbot]

Change https://go.dev/cl/633877 mentions this issue: internal/goexperiment: add a new experiment to gate DWARF version 5

[gopherbot]

Change https://go.dev/cl/634415 mentions this issue: cmd/internal/objabi,cmd/link/internal/sym: add SDWARFADDR symbol type

[gopherbot]

Change https://go.dev/cl/635836 mentions this issue: cmd/compile,cmd/link: move to DWARF5-style location lists

[thanm]

Update:

As reported by Alessandro, the binutils "objdump" command is complaining that the .debug_addr section being produced by the Go toolchain with GOEXPERIMENT=dwarf5 is malformed; I spent some time debugging objdump this morning after building a fresh copy from binutils tip, and I confirmed that this is indeed still the case. Here is an example:

$ go build himom.go
$ objdump --dwarf=addr himom > /dev/null
objdump: Warning: Corrupt .debug_addr section: expecting header size of 8 or 16, but found -14128 instead
$

Here's what's happening.

As currently implemented, the Go toolchain generates a single monolithic .debug_addr section entirely in the linker, as opposed to what C toolchains do, which is to have the compiler emit a .debug_frame section fragment for each translation unit and have them all glommed together by the linker when the final binary is written out.

The code binutils objdump is essentially mandating the C model, that is, it requires that there be a section header for each compilation unit (since this is what most C compilers do); it ignores the length field in the single .debug_addr header and instead for a given unit K, uses the DW_AT_addr_base value of unit K+1 as a proxy for the length of K's contributions. Code here, note the i+1:

https://github.com/bminor/binutils-gdb/blob/827f39f7e5d0c208275482cec979b9b5592c4aa8/binutils/dwarf.c#L7917

After it has finished printing the .debug_addr entries for unit K, it then requires that there be another section header immediately following, which it tries to validate (and fails, of course).

It is unfortunate that it works this way, since there is nothing in the DWARF standard that requires the "one header per compilation unit" model, and the hijacking or overloading of the DW_AT_addr_base value is not something recommended or talked about in the standard either as far as I know. The standard only says that DW_AT_addr_base gives the starting point for entries corresponding to CU K, it does not say anything about previous compilation units).

Also worth noting that the Go toolchain uses a similar monolithic section approach for .debug_frames as well, which objdump doesn't seem to mind.

I'll need to think about what to do about this.

[ianlancetaylor]

The fix for the GNU binutils seems fairly easy. Should we just send them a patch?

[thanm]

The fix for the GNU binutils seems fairly easy. Should we just send them a patch?

I agree it's worth doing this. I don't think it should block moving to DWARF 5 for Go, however.

[gopherbot]

Change https://go.dev/cl/656895 mentions this issue: internal/buildcfg: fix typo in DWARF 5 enabling code

[gopherbot]

Change https://go.dev/cl/656836 mentions this issue: runtime: increase GDB version testing requirement to 10 from 7.7

[gopherbot]

Change https://go.dev/cl/657175 mentions this issue: cmd/internal/dwarf: fix bug in inlined func DIE range DWARF 5 info

[gopherbot]

Change https://go.dev/cl/657177 mentions this issue: cmd/internal/dwarf: always use AT_ranges for scopes with DWARF 5

[gopherbot]

Change https://go.dev/cl/657176 mentions this issue: doc/next: add tentative DWARF 5 release note fragment

[thanm]

Update: DWARF 5 is now enabled at tip (for non-darwin and non-aix platforms) 🎉🎉🎉. I have fixed a few bugs, but so far things look good.

[cherrymui]

Hi @thanm , thank you for the great work! Is there anything we still need to do for this issue? Or we can close this? Thanks.

[thanm]

I think we can close the issue, thanks. I am still looking at issue #72810 which I think is some sort of book-keeping problem in the compiler, I hope to have a fix soon (I don't expect this to be a deal-breaker). Hopefully we can enable DWARF5 by default for darwin once the oldest supported xcode version includes the necessary support (e.g. V17).

[gopherbot]

Change https://go.dev/cl/663235 mentions this issue: cmd: fix DWARF gen bug with packages that use assembly

[thanm]

Closing out this issue since I now have a fix in flight for #72810.