Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: malformed DWARF ranges (child not contained in parent) #33188

thanm opened this issue Jul 19, 2019 · 9 comments

cmd/compile: malformed DWARF ranges (child not contained in parent) #33188

thanm opened this issue Jul 19, 2019 · 9 comments


Copy link

@thanm thanm commented Jul 19, 2019

What version of Go are you using (go version)?

$ go version
go version devel +79bb1a3653 Thu Jul 18 10:16:59 2019 -0400 linux/amd64

Does this issue reproduce with the latest release?


What operating system and processor architecture are you using (go env)?

go env Output
$ go env

What did you do?

Build this program:

package main

import "C"
import "log"

func main() {

in the usual way, e.g. "go build main.go". Then run

llvm-dwarfdump -verify -verbose main

to check the resulting dwarf.

What did you expect to see?

Clean run

What did you see instead?

A number of errors of the form: "error: DIE address ranges are not contained in its parent's ranges:"

Here is one instance:

0x00006511: DW_TAG_inlined_subroutine
              DW_AT_abstract_origin	(0x00000000000014b8 "runtime.add")
              DW_AT_ranges	(0x00001370
                 [0x0000000000004984, 0x0000000000004988)
                 [0x00000000000049f9, 0x00000000000049fe))
              DW_AT_call_file	("/ssd2/go/src/runtime/chan.go")
              DW_AT_call_line	(121)

which is contained in this DIE:

0x000064e4: DW_TAG_inlined_subroutine
              DW_AT_abstract_origin	(0x0000000000001696 "runtime.chanbuf")
              DW_AT_low_pc	(0x000000000000497c)
              DW_AT_high_pc	(0x0000000000004984)
              DW_AT_call_file	("/ssd2/go/src/runtime/chan.go")
              DW_AT_call_line	(484)

so definitely an inconsistency. Note that the top-level parent is:

0x0000640e: DW_TAG_subprogram
              DW_AT_name	("runtime.chanrecv")
              DW_AT_low_pc	(0x00000000000048a0)
              DW_AT_high_pc	(0x0000000000004f52)
              DW_AT_frame_base	(DW_OP_call_frame_cfa)
              DW_AT_decl_file	("/ssd2/go/src/runtime/chan.go")
              DW_AT_external	(0x01)

There is nothing in the DWARF spec as far as I know that mandates this sort of address range nesting consistency, but I think it would probably be nice if a given inlined subroutines ranges were completely nested inside the parent DIE.

Copy link

@aarzilli aarzilli commented Jan 3, 2020

For the record this did cause delve to misbehave #1795 but it's also very easy to work around inside delve (#1807)

Copy link

@petrhosek petrhosek commented Aug 14, 2020

We've recently ran into this issue as well when trying to generate GSYM files from Go binaries, see for additional discussion.

Copy link

@dr2chase dr2chase commented Aug 14, 2020

Do we still believe that this nesting is not actually mandated by the DWARF spec?
It seems like it would be easy for the bug-filers to direct us to the relevant requirements, if they exist.

@thanm thanm self-assigned this Aug 17, 2020
@thanm thanm added this to the Go1.16 milestone Aug 17, 2020
Copy link

@gopherbot gopherbot commented Aug 17, 2020

Change mentions this issue: cmd/compile: clean up buggy DWARF inlined info PC ranges

Copy link
Contributor Author

@thanm thanm commented Aug 19, 2020

Here is some more detail on what's happening in the compiler with this bug. There are two problems, one easy to fix and the other more difficult.

The first problem is that the code that computes ranges for inlined routines is not doing the book-keeping properly to insure that child ranges are included in parent ranges when handling nested inlines. This problem triggers the verifier's "DIE address ranges are not contained in its parent's ranges" error. I sent CL 248724 to fix this.

The second problem is trickier. The code that tracks variable scopes in the compiler is more or less independent from the code that handles inlining, meaning that when you have an inlined call whose callsite is positioned within a given lexical scope, the inlined routine DIE doesn't wind up as a child of the scope. This triggers a different error ("DIEs have overlapping address ranges").

Here is a reduced testcase that illustrates the second problem:

File a.go:

package a

func S(f, l, o int, v int) (err error) {
	var n = int32(v)
	return s(f, l, o, &n, 4)

func s(f, l, o int, v *int32, sz int) (err error) {
	defer func() { *v = 3 }()
	return nil

begin b.go:

package main

import "issue33188/a"

var gf, gl, gof int

func main() {
	for {
		var b [16]int
		e := a.S(gf, gl, gof, 33)
		if e == nil {
		gf += 9
		b[gf&3] += 1

Here's an abstracted version of the DWARF for main.main you get in this situation:

<1><f54>: Abbrev Number: 3 (DW_TAG_subprogram)
   <f55>   DW_AT_name        : main.main
   <f5f>   DW_AT_low_pc      : 0x45cd80
   <f67>   DW_AT_high_pc     : 0x45ce50
   <f6f>   DW_AT_frame_base  : 1 byte block: 9c 	(DW_OP_call_frame_cfa)
   <f71>   DW_AT_decl_file   : 0x2
   <f75>   DW_AT_external    : 1
<2><f76>: Abbrev Number: 20 (DW_TAG_lexical_block)
   <f77>   DW_AT_ranges      : 0x40
<3><f7b>: Abbrev Number: 11 (DW_TAG_variable)
   <f7c>   DW_AT_name        : b
   <f7e>   DW_AT_decl_line   : 9
   <f7f>   DW_AT_type        : <0x3cdc3>
   <f83>   DW_AT_location    : 0x0 (location list)
<3><f87>: Abbrev Number: 0
<2><f88>: Abbrev Number: 6 (DW_TAG_inlined_subroutine)
   <f89>   DW_AT_abstract_origin: <0xf0f>
   <f8d>   DW_AT_low_pc      : 0x45cde8
   <f95>   DW_AT_high_pc     : 0x45ce24
   <f9d>   DW_AT_call_file   : 0x2
   <fa1>   DW_AT_call_line   : 10
<3><fa2>: Abbrev Number: 19 (DW_TAG_formal_parameter)
   <fa3>   DW_AT_abstract_origin: <0xf21>
   <fa7>   DW_AT_location    : 0x35 (location list)
<3><fab>: Abbrev Number: 19 (DW_TAG_formal_parameter)
   <fac>   DW_AT_abstract_origin: <0xf29>
   <fb0>   DW_AT_location    : 0x68 (location list)
<3><fb4>: Abbrev Number: 19 (DW_TAG_formal_parameter)
   <fb5>   DW_AT_abstract_origin: <0xf31>
   <fb9>   DW_AT_location    : 0x9b (location list)
<3><fbd>: Abbrev Number: 14 (DW_TAG_variable)
   <fbe>   DW_AT_abstract_origin: <0xf4b>
   <fc2>   DW_AT_location    : 0xce (location list)
<3><fc6>: Abbrev Number: 0
<2><fc7>: Abbrev Number: 0

where the ranges for the lexical block containing "b" look like

             [0x000000000045cdaf, 0x000000000045cdf0)
             [0x000000000045ce24, 0x000000000045ce46))

which overlaps with the inlined routine but doesn't entirely contain it (and in addition the two DIEs in question are siblings within the main.main DIE, as opposed to having the scope parent the inline.

Fixing this is a good deal more complicated, since the two phases (scope generation and inline handling) operate more or less independently at the moment.

gopherbot pushed a commit that referenced this issue Nov 17, 2020
Repair the code that generates PC ranges for DWARF inlined routine
instances to insure that if II Y is a child of II X within the inline
tree, X's ranges include the ranges from Y. This is similar to what
we're already doing for DWARF scopes.

Updates #33188.

Change-Id: I9bb552777fcd1ae93dc01872707667ad092b1dd9
Run-TryBot: Than McIntosh <>
TryBot-Result: Go Bot <>
Reviewed-by: Cherry Zhang <>
Reviewed-by: David Chase <>
Trust: Than McIntosh <>
Copy link

@aclements aclements commented Dec 1, 2020

@thanm, can you update this bug with what still needs to be done? Should this still be for 1.16 or should we retarget the rest of the work to 1.17?

Copy link
Contributor Author

@thanm thanm commented Dec 1, 2020

can you update this bug with what still needs to be done? Should this still be for 1.16 or should we retarget the rest of the work to 1.17?

The part that's missing is integrating scope generation with inline generation, as mentioned before. This means (probably) unifying the mechanism used to represent scopes/inlines (scopes are stored using what amounts to a side table, whereas inlines are embedded into the Pos table).

I think it would be better to retarget this work for 1.17, since it seems as though it will require a fair number of changes. I think we would be better off landing it after the dev.regabi branch is merged, in particular.

@aclements aclements removed this from the Go1.16 milestone Dec 1, 2020
@aclements aclements added this to the Go1.17 milestone Dec 1, 2020
Copy link

@ianlancetaylor ianlancetaylor commented Apr 21, 2021

Is this likely to happen for Go 1.17, or should we shift the milestone?

Copy link
Contributor Author

@thanm thanm commented Apr 21, 2021

Unlikely to happen for 1.17 -- I will shift. Thanks.

@thanm thanm removed this from the Go1.17 milestone Apr 21, 2021
@thanm thanm added this to the Go1.18 milestone Apr 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants