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

Jump to bottom

cmd/compile: internal prefix paths leaking into generated DWARF #26311

Open
thanm opened this issue Jul 10, 2018 · 8 comments
Open

cmd/compile: internal prefix paths leaking into generated DWARF #26311

thanm opened this issue Jul 10, 2018 · 8 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. Debugging NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Unplanned

Comments

@thanm
Copy link
Contributor

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.
@ianlancetaylor ianlancetaylor added this to the Go1.11 milestone Jul 11, 2018
@ianlancetaylor ianlancetaylor added the NeedsFix The path to resolution is known, but the work has not been done. label Jul 11, 2018
@ianlancetaylor ianlancetaylor modified the milestones: Go1.11, Go1.12 Jul 11, 2018
@thanm
Copy link
Contributor 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
Copy link
Contributor

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
Copy link
Contributor Author

thanm commented Dec 18, 2018

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

@aarzilli
Copy link
Contributor

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
Copy link
Contributor 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
Copy link
Contributor

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?

@josharian
Copy link
Contributor

@thanm @aarzilli can this wait for 1.14? Or move to unplanned?

@thanm thanm modified the milestones: Go1.13, Unplanned Jun 3, 2019
@thanm
Copy link
Contributor Author

thanm commented Jun 3, 2019

I've moved to unplanned. I am now thinking that maybe this is best handled in delve, better to leave the mangling in place.

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. Debugging NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
6 participants
@josharian @aarzilli @ianlancetaylor @gopherbot @thanm @heschi