cc @golang/compiler

cc @thanm

Related Issues

• cmd/compile: malformed DWARF ranges (child not contained in parent) #33188
• debug/dwarf: r.Next() returns wrong ent when DWARF5 used. #57046 (closed)
• cmd/compile: incorrect abstract origin assigned to param of inlined subroutine #23020 (closed)
• cmd/compile: missing variables in debug_info for inlined subroutines #24460 (closed)
• cmd/compile: DWARF information for local variables missing #14744 (closed)
• cmd/compile: autotmp_ variables included in DWARF #17644 (closed)
• cmd/compile: DWARF inlined function call line not adjusted by //line #58648 (closed)
• cmd/link: .debug_pubnames and .debug_pubtypes not following DWARF4 spec #30573 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

Thanks. I see the problem -- fix en route.

What's happening in this bug is that we're trying to emit the hi/lo PC values for a given inlined func using FORM_addrx for lo and offset for hi, which is a non-starter, since FORM_addrx at the moment can only be used for addresses corresponding to the start of a func, not the middle of a function.

I am going to fix this bug by changing the compiler to unconditionally use DW_AT_ranges for inlined subroutines, even those with only a single range.

Background: prior to this point, if a given inlined function body had a single contiguous range, we'd pick an abbrev entry for it with explicit DW_AT_low_pc and DW_AT_high_pc attributes. If the extent of the code for the inlined body was not contiguous (which can happen), we'd select an abbrev that used a DW_AT_ranges attribute instead. This strategy (preferring explicit hi/lo PC attrs for a single-range func) made sense for DWARF 4, since in DWARF 4 the representation used in the .debug_ranges section was especially heavyweight (lots of space, lots of relocations), so having explicit hi/lo PC attrs was less expensive.

With DWARF 5, range info is written to the .debug_rnglists section, and the representation here is much more compact. Specifically, a single hi/lo range can be represented using a base address in addrx format (max of 4 bytes, but more likely 2 or 3) followed by start and endpoints of the range in ULEB128 format. This combination is more compact spacewise than the explicit hi/lo values, and has fewer relocations (0 as opposed to 2).

Note: we should at some point consider applying this same strategy to lexical scopes, since we can probably reap some of the same benefits there as well.

@aarzilli please weigh in if you can see any issues with moving in this direction.

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