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

Open
thanm opened this Issue Jul 10, 2018 · 6 comments

Comments

Projects
None yet
4 participants
@thanm
Copy link
Member

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?

Yes

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

linux/amd64

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 (
	"fmt"

	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
0
(gdb)

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

@thanm

This comment has been minimized.

Copy link
Member Author

thanm commented Dec 18, 2018

Not going to happen in Go 1.12

@thanm thanm modified the milestones: Go1.12, Go1.13 Dec 18, 2018

@aarzilli

This comment has been minimized.

Copy link
Contributor

aarzilli commented Dec 18, 2018

I should point out that removing the mangling will make parsing the names (even) harder. Is b.ev1.q symbol q of package q.ev1 or method q with receiver type ev1 in package b?

@thanm

This comment has been minimized.

Copy link
Member Author

thanm commented Dec 18, 2018

Are clients (e.g. delve) actually relying on mangling to disambiguate names right now?

@aarzilli

This comment has been minimized.

Copy link
Contributor

aarzilli commented Dec 18, 2018

Yes. Specifically on the fact that the last component of the package path doesn't contain periods.
Also looking at your example again, I don't think just removing the mangling is enough. I haven't used gdb much and I haven't tried this but wouldn't you have to type the full path, as in p issue26237/b.ev1.q anyway?

@thanm

This comment has been minimized.

Copy link
Member Author

thanm commented Dec 18, 2018

I assume that the DWARF will have whatever package path was passed to the compiler, so yes, it seems that you would need to know this. The question in my mind is: what should we tell users -- it seems unpleasant (to me) to leave the mangling in and tell users about it ("To print a global variable V in package P, form the string "P.V" but replace all dots in P with %2e ..." or something to this effect). On the other hand if putting the unmangled name into DWARF is going to break Delve, though, then perhaps this is the right way to go.

@aarzilli

This comment has been minimized.

Copy link
Contributor

aarzilli commented Dec 19, 2018

The question in my mind is: what should we tell users -- it seems unpleasant (to me) to leave the mangling in and tell users about it ("To print a global variable V in package P, form the string "P.V" but replace all dots in P with %2e ..." or something to this effect).

I don't disagree with this.

On the other hand if putting the unmangled name into DWARF is going to break Delve, though, then perhaps this is the right way to go.

Delve can be changed. This issue just needs to be careful not to introduce ambiguities. Maybe always putting the receiver in parentheses is enough?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.