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

proposal: cmd/objdump: add '-gnu-only' or '-mca' flag #52099

Open
ericlagergren opened this issue Apr 1, 2022 · 14 comments
Open

proposal: cmd/objdump: add '-gnu-only' or '-mca' flag #52099

ericlagergren opened this issue Apr 1, 2022 · 14 comments

Comments

@ericlagergren
Copy link
Contributor

@ericlagergren ericlagergren commented Apr 1, 2022

A popular tool for profiling assembly code is llvm-mca, which ingests assembly and outputs statistics. However, it does not accept Go's assembly syntax. In order to use it with Go, you have to convert Go's assembly to GNU (or other) assembly.

Converting from Go's assembly is difficult. Currently, the best way to do this is to compile the Go code and use go tool objdump -gnu or objdump and parse the output with Perl/awk/sed/whatever. This is fraught, especially when cmd/objdump does not understand the Go executable (see #52098).

I propose adding a flag to cmd/objump to only output GNU or other assembly that the output can be directly ingested by tools like llvm-mca.

I am also open to alternatives. I really just want Go to work with llvm-mca. :)

@gopherbot gopherbot added this to the Proposal milestone Apr 1, 2022
@ericlagergren ericlagergren changed the title proposal: cmd/asm: output 'GNU' assembly proposal: cmd/asm: add a flag to output 'GNU' assembly Apr 1, 2022
@beoran
Copy link

@beoran beoran commented Apr 1, 2022

Why not use gccgo to compile the Go to assembly? https://go.dev/doc/install/gccgo

@cherrymui
Copy link
Member

@cherrymui cherrymui commented Apr 1, 2022

cmd/asm is the assembler, i.e. taking text input to convert to binary. It is not a disassembler. The -S output is mainly for debugging purposes. I don't think cmd/asm is the right place to do it.

@ericlagergren
Copy link
Contributor Author

@ericlagergren ericlagergren commented Apr 1, 2022

@cherrymui yeah, I was waffling over whether to make this for cmd/asm or cmd/objdump. If you think that's a better place to put it then I'll update the proposal.

@cherrymui
Copy link
Member

@cherrymui cherrymui commented Apr 1, 2022

cmd/objdump already has a -gnu flag. It may not understand all instructions and have room to improve. But that doesn't need a new proposal.

@ericlagergren
Copy link
Contributor Author

@ericlagergren ericlagergren commented Apr 1, 2022

@beoran A few reasons.

First, I don't have gccgo installed on my system (macOS) and frankly I'm not entirely sure how to. It appears Homebrew's gcc candidate does not build the Go frontend. I'd also have to install gccgo for each system I write assembly for.

Second, given a Go assembly file, will gccgo output the same assembly as gc?

And, finally, all my assembly code is //go:build gc anyway. Maybe that's wrong, but—like I mentioned above—I don't test against gccgo.

@ericlagergren
Copy link
Contributor Author

@ericlagergren ericlagergren commented Apr 1, 2022

@cherrymui My "proposal" (for lack of a better word) would be a -gnu-only or -mca flag. What sort of GitHub issue should I file?

@ericlagergren ericlagergren changed the title proposal: cmd/asm: add a flag to output 'GNU' assembly proposal: cmd/objdump: add '-gnu-only' flag Apr 1, 2022
@ericlagergren ericlagergren changed the title proposal: cmd/objdump: add '-gnu-only' flag proposal: cmd/objdump: add '-gnu-only' or '-mca' flag Apr 1, 2022
@cherrymui
Copy link
Member

@cherrymui cherrymui commented Apr 1, 2022

Okay, you can just update this proposal.

But why not use the system objdump, then? In my opinion if the main purpose is to interacting external tools, it doesn't need to be in the Go distribution. You can write your own tool.

@ericlagergren
Copy link
Contributor Author

@ericlagergren ericlagergren commented Apr 1, 2022

The typical usage for llvm-mca is to feed it assembly directly from the compiler, e.g. gcc -S x.c | llvm-mca.

Parsing the output of system ojbdump is a fraught endeavor. The output (as well as flags/options) can differ across installations (GNU or BSD) and versions. Afterward, you have to (often significantly) fix up the output to make it valid assembly.

Using cmd/objdump simplifies all that—you only have to parse one tool, not N. Plus, the "GNU assembly comments" that cmd/objdump emits alongside the Go assembly (via the -gnu flag) can already be fed directly to llvm-mca. The only hurdle is parsing cmd/objump, which is neither standardized nor machine readable.

Which is why I'd like cmd/objdump to support printing something more usable.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Apr 2, 2022

Doing this would not address the calling convention differences. Even if you could convert from Go assembler syntax to GNU assembler syntax, you couldn't call the resulting functions directly, because the calling convention is different.

@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Apr 2, 2022
@ericlagergren
Copy link
Contributor Author

@ericlagergren ericlagergren commented Apr 2, 2022

@ianlancetaylor yes. But the purpose (well, my purpose) isn't to run it directly, it's to analyze it.

@beoran
Copy link

@beoran beoran commented Apr 2, 2022

Another, slightly more difficult solution could be to write a tool that works like llvm-mca but does understand Go assembly. Probably we could use the source code of the Go assembler to help with this?

@rsc
Copy link
Contributor

@rsc rsc commented Jun 22, 2022

There is already go tool objdump -gnu.
If that's not good enough, why not use llvm-objdump instead?
In general the main Go toolchain is not aiming to keep up with any other toolchains:
that's work we're not committing to.
The separate go-llvm-mca seems like a good approach to me if llvm-objdump is for some reason not acceptable.

@rsc rsc moved this from Incoming to Active in Proposals Jun 22, 2022
@rsc
Copy link
Contributor

@rsc rsc commented Jun 22, 2022

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

@rsc
Copy link
Contributor

@rsc rsc commented Jul 1, 2022

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

@rsc rsc moved this from Active to Likely Decline in Proposals Jul 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
Likely Decline
Development

No branches or pull requests

6 participants