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/nm: decide on symbol index presentation #38875

Open
josharian opened this issue May 5, 2020 · 5 comments
Open

cmd/nm: decide on symbol index presentation #38875

josharian opened this issue May 5, 2020 · 5 comments

Comments

@josharian
Copy link
Contributor

@josharian josharian commented May 5, 2020

Sample reproduction:

Run go tool nm ../pkg/darwin_amd64/net.a. With tip, I see entries like:

../pkg/darwin_amd64/net.a(_go_.o):        1bedb2 T net.(*TCPConn).readFrom#423

Note the trailing #423. Those are not present with Go 1.14:

../pkg/darwin_amd64/net.a(_go_.o):         a5e67 T net.(*TCPConn).readFrom

cc @cherrymui @jeremyfaller @thanm

@josharian josharian added this to the Go1.15 milestone May 5, 2020
@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented May 5, 2020

Yeah, this was done in CL https://go-review.googlesource.com/c/go/+/229246 . The reason is that in the new object files, symbols are referenced by indices instead of by names. So, if you objdump an object file which imports the fmt package and call fmt.Printf, instead of CALL fmt.Printf, you'll see CALL fmt.#33. The object file itself doesn't have any information about what name that symbol actually is. To make it more usable, I think there should be a way to tell what symbol #33 is in the fmt package, and nm fmt.a seems a natural place to me. Therefore I added the index to the symbol name.

Does this format cause any problem for you? Should we add a flag to switch it on/off? I'd also be happy to hear if you have a better suggestion of the format. Thanks!

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented May 5, 2020

@aclements
Copy link
Member

@aclements aclements commented May 5, 2020

I just added a RELNOTE marker on that CL. It may be worth mentioning this to golang-dev@, too, since I imagine Josh won't be the only person surprised by this!

@josharian
Copy link
Contributor Author

@josharian josharian commented May 5, 2020

Does this format cause any problem for you? Should we add a flag to switch it on/off? I'd also be happy to hear if you have a better suggestion of the format. Thanks!

It confused some tools I have that parse the output of go tool nm. Easy enough to unmangle, now that I know I can safely ignore the numbers.

Although there would be some value in having a flag (default on or off? not sure.) Or maybe another column in the output for easier parsing (perhaps enabled by a flag)? Those would move the knowledge about how to unmangle from N tools--each possibly using different algorithms and thus getting it wrong in the future in different ways--to one tool.

An alternative, which I would like even better, since I would no longer have to exec nm, would be to expose cmd/internal/objfile, maybe without a Go 1 compatibility guarantee, or living in the Go 1 compat gray zone that other rarely used packages like debug/* occupy. Then we could just add a field for the index instead of having to squish it into the name,

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented May 5, 2020

Or maybe another column in the output for easier parsing

I originally had a space between the index and the name. Austin pointed out that adding a space may makes tools harder to parse.

@aclements aclements changed the title cmd/nm: many symbol names contain # (regression from 1.14) cmd/nm: decide on symbol index presentation Jun 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.