[WebAssembly] Use WebAssembly custom sections in C/C++ source files

[nokotan]

All global variables, including ones that have section attribute __attribute__((section("<section-name>"))), are located in WebAssembly data sections.

I know that this behavior is required to compatibility of other platforms, and that this is great solution because all data in WebAssembly custom section cannot be loaded into a linear memory.

If you want to embed some metadata into WebAssembly, file scope inline assembly can be used.

__asm(
  ".section .custom_section.my_section,\"G\",@,abc123\n"
  ".ascii \"my_section is here!\"\n"
);

I want global variables, attributed __attribute__((section(".custom_section.*"))) and never read and written in the program, to be located into WebAssembly custom section.
This may be solution candidate of that llvm-cov is useless with WebAssembly because llvm-cov currently expects that llvm-cov specific sections are located in WebAssembly custom section. (emscripten-core/emscripten#13046)

[llvmbot]

@llvm/issue-subscribers-backend-webassembly

[sbc100]

Anther solution the llvm-cov problem is to update the way libObject handles data segments. As of today the individual data segments are not listed as separate in ObjectFile::sections()... but I think they they should be. I've got a discussion started here but I've made much progress recently: WebAssembly/tool-conventions#138

The idea is that when you build with -fdata-sections and/or -ffunction-sections you expected the resulting tools to display one section per symbol.. but today we don't do that with wasm.. which I think its bug.

[nokotan]

Now I agree with It could be better way that writing data segment metadata into wasm binary, like WasmWriter::writeSectionContent(_, WasmYAML::LinkingSection) does, when -fdata-sections specified than directly write data segments into wasm custom section.

Originally I hoped this feature in order to use writing wasm-bindgen's metadata in C/C++ source files, which currently leads me to preprocessors macro hell... It won't be a good wasm-JavaScript bindings generation tool for C/C++ unlike emscripten's webidl binder or wit-bindgen.