Provide clang flag to opt out of `wasm-opt` when linking wasm?

[TerrorJack]

Currently, when linking wasm, clang attempts to detect wasm-opt in the environment, and invokes it with certain flags based on current optimization level. source

This behavior is undesirable when user wants to customize when or how wasm-opt is run. It would be nice if a clang command line flag can be provided to opt-out of this behavior.

[llvmbot]

@llvm/issue-subscribers-clang-driver

[abrown]

cc: @sunfishcode, @sbc100, @tlively or anyone else who may have worked on this: what do you all think about retaining the name custom section by default in wasm-opt and only removing it when the optimization level is explicitly dialed up? This section is quite useful for populating backtraces, e.g., and I was confused when the name section magically disappeared in a build.

[sbc100]

I think the simplest thing would be to preserve it in all cases. If folks want to strip it they can use -Wl,--strip-debug which already exists today.

I think it might be as simple as adding -g unconditionally to wasm-opt (although that might end up add a name section to the binary where non existed previously... I think we should fix that on the wasm-opt side if that is the case).

[sbc100]

In other words, let wasm-ld decide what debug into to include, and ask wasm-opt to do its best to preserve it.

[abrown]

Should I submit a change request to add -g unconditionally to the driver?

[aheejin]

Adding -g to the driver invocation in the clang driver is one way.

I think another way might be to just, change binaryen's behavior so that even without -g given, we preserve the debug info. I checked with clang and llc and they preserve the existing debug info without -g given.

For example, if I create test.ll using

clang -g test.c -c -emit-llvm -o test.ll

And finish compiling test.ll to test.o using clang -g or llc,

llc -filetype-obj test.ll -o test.o

clang -c test.ll -o test.o

Even though the second llc and clang don't have -g, they preserve the debug info. But this changes binaryen's current behavior, so I can be unaware of potential consequences. Thoughts? @kripken

[kripken]

@aheejin Hmm, I think changing binaryen may be a little risky. It's a change to a long-existing user interface and the result could be people shipping name sections unnecessarily without noticing it (if they don't measure code size).

Also, there is a reason binaryen differs from llc - llc's inputs all know if they have debug info or not, so it's natural to preserve debug info as it was in the input. But wasm-opt can also receive as input a wat file which doesn't say if it has debug info or not, so we need user input to tell us whether to emit a names section. It made more sense in the past when binaryen had a second input format without clear debug info (asm2wasm / asm.js), so I guess it's debatable. And also clang has mixed behavior, requiring -g for source files but preserving debug info on object files automatically IIUC.

Still, for the reasons in the first paragraph I think it's better not to change binaryen here. Instead, could clang pass -g to wasm-opt when it received -g itself?

[abrown]

@kripken, I also was thinking along the lines of "conditionally pass -g along" but I couldn't figure out how this might work when wasm-ld is used directly. I don't see that it has a -g flag to pass along — were you thinking we should add one?

[sbc100]

Its in the clang driver linked above:

llvm-project/clang/lib/Driver/ToolChains/WebAssembly.cpp

Line 133 in 940e290

// When optimizing, if wasm-opt is available, run it.

wasm-ld never calls wasm-opt itself.. its something that run after wasm-ld.

[sbc100]

Also, I think its has to be unconditional since wasm-ld will produce debug info based on input object files, and not based on the -g flag passed to clang at link time. In fact, I think clang ignores -g at link time.

Assuming wasm-opt -g means don't strip debug info, but also don't generate any then I think its fine to make it unconditional.

[kripken]

Assuming wasm-opt -g means don't strip debug info, but also don't generate any then I think its fine to make it unconditional.

Unfortunately that's not true. Binaryen IR doesn't mention the presence or lack of debug info. That is, having or not having a names section is something the wasm binary format has, but not the text format, and not Binaryen IR which abstracts over both the text and binary format. Atm wasm-opt -g will emit a name section using the names used in the IR (which, if there wasn't a names section, will be things like $0).

But if there isn't a better solution, then adding that might be ok. We already have hasFeaturesSection, and could add hasNamesSection + handling for it.