emscripten-core / emscripten-core/emscripten

`-gseparate-dwarf` contains copy of the original .wasm file

Open
#13,084 14 comments 0 reactions 1 assignee Claimed by @dschuff View on GitHub
Dominant language
C++
Stars
27.6k
Forks
3.6k
Avg merge
1d 1h
Merged PRs (30d)
105

Description

Consider this simple example `hello.c`:

```c
int main(int argc, char** argv) {
return 0;
}
```

Compiling this with `-gseparate-dwarf` yields:

```console
$ emcc --version
emcc (Emscripten gcc/clang-like replacement) 2.0.11 (6e28e4fa4fa1bc50d58b9ddbbb9603a3cf21ea9e)
Copyright (C) 2014 the Emscripten authors (see AUTHORS.txt)
This is free and open source software under the MIT license.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ emcc -gseparate-dwarf -o hello hello.c
shared:INFO: (Emscripten: Running sanity checks)
$ wasm-objdump -h hello.wasm*

hello.wasm: file format wasm 0x1

Sections:

Type start=0x0000000e end=0x00000033 (size=0x00000025) count: 7
Function start=0x00000039 end=0x0000004b (size=0x00000012) count: 17
Table start=0x00000051 end=0x00000056 (size=0x00000005) count: 1
Memory start=0x0000005c end=0x00000062 (size=0x00000006) count: 1
Global start=0x00000068 end=0x0000007b (size=0x00000013) count: 3
Export start=0x00000081 end=0x00000155 (size=0x000000d4) count: 12
Code start=0x0000015b end=0x0000031f (size=0x000001c4) count: 17
Custom start=0x00000325 end=0x0000045a (size=0x00000135) "name"
Custom start=0x0000045c end=0x00000486 (size=0x0000002a) "external_debug_info"

hello.wasm.debug.wasm: file format wasm 0x1

Sections:

Type start=0x0000000e end=0x00000033 (size=0x00000025) count: 7
Function start=0x00000039 end=0x0000004b (size=0x00000012) count: 17
Table start=0x00000051 end=0x00000056 (size=0x00000005) count: 1
Memory start=0x0000005c end=0x00000062 (size=0x00000006) count: 1
Global start=0x00000068 end=0x0000007b (size=0x00000013) count: 3
Export start=0x00000081 end=0x00000155 (size=0x000000d4) count: 12
Code start=0x0000015b end=0x0000031f (size=0x000001c4) count: 17
Custom start=0x00000325 end=0x0000045a (size=0x00000135) "name"
Custom start=0x00000460 end=0x000004e0 (size=0x00000080) ".debug_info"
Custom start=0x000004e6 end=0x00000540 (size=0x0000005a) ".debug_abbrev"
Custom start=0x00000546 end=0x0000059a (size=0x00000054) ".debug_line"
Custom start=0x000005a0 end=0x0000068d (size=0x000000ed) ".debug_str"
```

All the Wasm code and everything else now exists twice, once in the main `hello.wasm` and once in the `hello.wasm.debug.wasm` sidecar. This seems to be due to the [relevant logic in `building.py`](https://github.com/emscripten-core/emscripten/blob/42120203eda7c5437a050c4a5b46c83c942226ef/tools/building.py#L1356-L1395), which first moves the `hello.wasm` file to `hello.wasm.debug.wasm`, and afterwards uses `objcopy` to copy back all non-`.debug*` sections to `hello.wasm`.

Now this is a trivial example, but with larger applications compiled for debugging, i.e. `-O0 -g -fno-inline` as we currently recommend, the amount of duplicated information is massive (easily 100+MiB), which the DWARF debugging extension has to fetch and keep in memory.

Ideally, the logic in `building.py` would be inversed, and use

1. `objcopy` to copy out the `.debug*` sections into the `hello.wasm.debug.wasm`, and
2. afterwards run `strip` on the `hello.wasm` file to remove all traces of debugging information.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.