-gseparate-dwarf reads like it shoud work like -gsplit-dwarf(?), but doesn't #17814
Description
After talking with @dschuff about our Wasm debugging troubles, he suggested using the -gseparate-dwarf option to create separate DWARF object files (.dwo), 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
int foo(int a, int b)
{
return a + b;
}b.cpp
#include <stdio.h>
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 infotest.wasm.debug.wasm: contains the debug info sections fortest.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
" 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:
(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!