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

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.

@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.

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.

@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.

@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?

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.

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.

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 yes. But the purpose (well, my purpose) isn't to run it directly, it's to analyze it.

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?

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.

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

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

No change in consensus, so declined.
— rsc for the proposal review group