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: internal prefix paths leaking into generated DWARF #26311

thanm opened this Issue Jul 10, 2018 · 0 comments


None yet
3 participants

thanm commented Jul 10, 2018

Please answer these questions before submitting your issue. Thanks!

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

go version devel +c78b7693ab Tue Jul 10 05:08:40 2018 +0000 linux/amd64

however this same problem appears to be present in older released (1.10, 1.9 etc)

Does this issue reproduce with the latest release?


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


What did you do?

Within my GOPATH, I have a subdir "b.v1" containing b.go:

$ cat b.v1/b.go
package b

var q int

func Top(x int) int {
	q += 1
	if q != x {
		return 3
	return 4

func OOO(y int) int {
	defer func() { q += Top(y) }()
	t := q
	q = y * y
	return t

then a main program that imports the package b:

package main

import (

	b "b.v1"

var z int

func main() {
	z = b.OOO(z)
	if b.Top(1) != 2 {
		fmt.Printf("Beware the Jabberwock, my son!\n")

When I compile this program and look at the generated DWARF, it appears that the package path for things in "b" have been mangled (for functions and variables -- compile unit still shows the correct path):

 <1><7324d>: Abbrev Number: 3 (DW_TAG_subprogram)
    <7324e>   DW_AT_name:         issue26237/b%2ev1.Top
    <73264>   DW_AT_inline:       1	(inlined)
    <73265>   DW_AT_external:     1
 <2><73266>: Abbrev Number: 16 (DW_TAG_formal_parameter)
    <73267>   DW_AT_name:         x
    <73269>   DW_AT_variable_parameter: 0
    <7326a>   DW_AT_type:         <0x128a>
 <2><7326e>: Abbrev Number: 0
 <1><14ec2>: Abbrev Number: 7 (DW_TAG_variable)
    <14ec3>   DW_AT_name:         issue26237/b%2ev1.q
    <14ed7>   DW_AT_location:     9 byte block: 3 80 8f 56 0 0 0 0 0 	(DW_OP_addr: 568f80)
    <14ee1>   DW_AT_type:         <0x128a>
    <14ee5>   DW_AT_external:     1

Note the "%2ev1". It looks like this mangling is being done in PathToPrefix() in cmd/internal/objabi, no doubt to hide/mangle the "." within the name.

While it seems fine to do mangling within the compiler, it doesn't seem as though the mangling should be leaking into the generated DWARF -- names there should reflect the original package path. If I build this program and run GDB on it, I can't print out the value of the variable 'q' without knowing the special mangled name, which seems unfriendly.

What did you expect to see?

(gdb) p b.v1.q

What did you see instead?

(gdb) p 'b.v1.q'
No symbol "b.v1.q" in current context.

@heschik heschik added the Debugging label Jul 10, 2018

@ianlancetaylor ianlancetaylor added this to the Go1.11 milestone Jul 11, 2018

@ianlancetaylor ianlancetaylor modified the milestones: Go1.11, Go1.12 Jul 11, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment