Try to (re)generate assembly sources

[P403n1x87]

It would be cool if the extension auto-generated the assembly sources. What I have to run is

gcc -g -o src/some_source.S -S src/some_source.c -masm=intel

which could be automated by just grabbing the path of the active text editor and adding it to a command template. Configuration could be extended to also allow for the asm flavour, but that's for a different issue.

[dseight]

Unfortunately, it's all usually not that easy. This might work for simplest cases, but for most real-world projects this won't work, as the compiler needs to know lots of compilation flags.

So, my opinion on this, is that asm should be generated for the whole project by modification of CFLAGS (e.g. by addition of -save-temps option).

[verhovsky]

@dseight can you reconsider? I think there's a lot more potential "casual" uses/users of this tool. Setting up this compilation stuff in a Makefile and then having to open a terminal, cd into the correct directory and running make watch every time I restart VS Code (or just close and re-open the project(s) I want to use this extension with) is tedious. Your extension could get a lot more use if it could be used without configuration.

I don't want to compile complex real-world projects, I just want to open a C file and see what "hello world" or simple functions compile into, out of curiosity. I don't want to set up Makefiles and create temporary .S files. When I go to https://godbolt.org/ everything is right there, I just write C code and see the assembly, I don't have to know anything about compilers or their flags or configure stuff, it just lets me type text and shows me a result. This extension should do the same. There's only 3 operating systems and 3 C compilers, on Linux you need to check for gcc then clang, on macOS for clang then gcc, on Windows for MSVC then gcc then clang and then

const child_process = require("child_process");

let compilerPath = findCompiler() || 'cc';
const result = child_process.spawnSync(compilerPath, ["-g", "-x", "c", "-", "-o", "/dev/stdout", "-S", "-fno-verbose-asm"], { input: vscode.window.activeTextEditor.document.getText() }).stdout;

Next, you could implement support for VS Code's already built in compilation settings. In order to get proper syntax highlighting of C code you usually have to configure .vscode/c_cpp_properties.json which should contain all the information the extension should need to build my project. If I'm able to get CodeLLDB to compile and launch my project and then debug assembly matched up to a specific line of C code, it doesn't make sense that I would then have to do a completely separate configuration step for this extension.

[dseight]

I don't want to compile complex real-world projects, I just want to open a C file and see what "hello world" or simple functions compile into, out of curiosity.

And this is what godbolt.org is here for! Seriously, Compiler Explorer is a perfect match to do this very thing. You can even run your local instance of it if you wish (and if you must keep your code locally for some reason).

This extension, on the other hand, was made for a completely different purpose: to see what your big project will compile into, and how things like -flto or --param aarch64-autovec-preference=1 will affect your final assembly.

So no, this is not something that I'll reconsider in the near future.