-gseparate-dwarf reads like it shoud work like -gsplit-dwarf(?), but doesn't

After talking with @dschuff about our Wasm debugging troubles, he suggested using the `-gseparate-dwarf` option to create separate [DWARF object files (.dwo)](https://gcc.gnu.org/wiki/DebugFission), with the impression that it would work like `-gsplit-dwarf` build option.

The documentation reads a bit similar:

```
``-gseparate-dwarf[=FILENAME]``
[same as -g3 if passed at compile time, otherwise applies at link]
Preserve debug information, but in a separate file on the side. This is the
same as ``-g``, but the main file will contain no debug info. Instead, debug
info will be present in a file on the side, in ``FILENAME`` if provided,
otherwise the same as the wasm file but with suffix ``.debug.wasm``. While
the main file contains no debug info, it does contain a URL to where the
debug file is, so that devtools can find it. You can use
``-sSEPARATE_DWARF_URL=URL`` to customize that location (this is useful if
you want to host it on a different server, for example).
```

If I have files
`a.cpp`
```cpp
int foo(int a, int b)
{
return a + b;
}
```
`b.cpp`
```cpp
#include

int foo(int a, int b);

int main()
{
printf("%d\n", foo(1, 2));
}
```

From the doc, I get the idea that `emcc a.cpp b.cpp -o test.js -gseparate-dwarf` would produce:
- `test.wasm`: contains the compiled output code with no debug info
- `test.wasm.debug.wasm`: contains the debug info sections for `test.wasm`

But this is not the case. The file `test.wasm` indeed does not contain DWARF info (though it does still contain the Wasm `NAME` section for function names), but the file `test.wasm.debug.wasm` is not just a debug info container, but it is a full copy of the program, plus with the DWARF debugging info intact.

I.e. it seems that `emcc a.cpp b.cpp -o test.html -gseparate-dwarf` is essentially an alias to writing the two commands

`emcc a.cpp b.cpp -o test.js -g2`
`emcc a.cpp b.cpp -o test.wasm.debug.js -g3`

Is this intentional?

---

A sidenote thought: the naming `test.wasm.debug.wasm` is maybe not ideal? Could this instead be renamed to `test.debug.wasm`?

---

Then a second observation: the GCC `-gsplit-dwarf` option does not seem to work with Wasm. The [original GCC docs state that](https://gcc.gnu.org/wiki/DebugFission)

" Use the -gsplit-dwarf option to enable the generation of split DWARF at compile time. This option must be used in conjunction with -c; Fission cannot be used when compiling and linking in the same step. "

i.e. my understanding here is that natively one would run

```
g++ -c a.cpp -o a.o -gsplit-dwarf
g++ -c b.cpp -o b.o -gsplit-dwarf
g++ a.o b.o -o test.exe
```
to produce an executable with separate `a.dwo` and `b.dwo` debug info files? (similar to how Microsoft's separate PDB files work?)

It seems that the `-gsplit-dwarf` option does not work with Emscripten: at `-c` compile commands it is getting ignored, but at link stage, it does generate a `.dwo` file, which is basically an empty Wasm object file:
```wast
(module
;; custom section "producers", size 112
)
```

And the `-gseparate-dwarf` option does not currently also work to separate/split DWARF debug info into distinct `.dwo`/`.wasm` files: rather it can only be used to generate a copy of the full output program with DWARF intact?

---

Is the above accurate? Should there exist a method to generate separate individual per-object debugging symbol files that Chrome Wasm DWARF debugger could consume?

The issue with Chrome debugger is that it chokes at Unity scale of DWARF output, hanging when the very large DWARF enabled .wasm files are fed to it - hence looking for a way to split the debug info into separate per-object DWARF files. With the current `-gseparate-dwarf`, it does not help Chrome debugger, since there is still one big Wasm code+DWARF file present.

Or maybe I missed some step? Thanks!