Option for compiling stdlib with debug symbols

[emaxx-google]

By default, Emscripten compiles the C/C++ standard libraries without debug symbols. This can be checked by running llvm-dwarfdump on files from upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/. This causes troubles when debugging crashes that happen inside the standard library functions.

Can there be a simple way for forcing debug symbols (-g) in the standard library built by Emscripten?

The current workaround is, for example, to hack emcc.py to always specify -g regardless of the input parameters.

[kripken]

Weird. I remember @sbc100 changed our builds to contain debug info. I see that happened in #13078

Indeed, when I run llvm-dwarfdump cache/sysroot/lib/wasm32-emscripten/libc.a I get debug info, for example.

I also verified by running dwarfdump on the precompiled libraries the emsdk arrives with.

So it looks ok to me both when I compile the system libraries locally, and get them from the emsdk. And to be sure we're talking about the same thing, this is a sample of my dwarfdump output:

0x00000034:   DW_TAG_subprogram
                DW_AT_low_pc    (0x00000003)
                DW_AT_high_pc   (0x0000008e)
                DW_AT_frame_base    (DW_OP_WASM_location 0x0 0x2, DW_OP_stack_value)
                DW_AT_GNU_all_call_sites    (true)
                DW_AT_name  ("cacos")
                DW_AT_decl_file ("/home/azakai/Dev/emscripten/system/lib/libc/musl/src/complex/cacos.c")
                DW_AT_decl_line (7)

What precise output do you get from llvm-dwarfdump? Also, what size is say libc.a? (for me it is 2724314 locally, 2722174 from the emsdk)

[sbc100]

Maybe you are using a older version of emscripten prior to #13078 landing? I think the first version to include that change was 2.0.14.

[emaxx-google]

Hmm, I'm using 2.0.24. But my checkout was originally created before that change - could it be that some libraries in the cache survived since then? I can repeat my test in a fresh checkout and see if the problem repros.

[emaxx-google]

I verified that in a fresh checkout the debug symbols are there. Not sure how my old checkout went into this weird state (with a new Emscripten version, but without debug symbols in stdlibs). Does one need to run emcc --clear-cache after every update?

[emaxx-google]

Another thing I just noticed: it seems that by default Emscripten fetches prebuilt standard libraries? Symbols in these prebuilts don't work properly in DevTools, as the file paths point to locations on the bots:

Could not load content for file:///b/s/w/ir/k/install/emscripten/system/lib/pthread/library_pthread.c (System error: net::ERR_FILE_NOT_FOUND)

[RReverser]

Symbols in these prebuilts don't work properly in DevTools, as the file paths point to locations on the bots:

You can override paths in the C++ extension and remap those bot paths to either local Emscripten checkout or even Github URLs: https://developer.chrome.com/blog/wasm-debugging-2020/#path-mapping

[kripken]

Does one need to run emcc --clear-cache after every update?

Not usually. A version number change will clear the cache, unless you set FROZEN_CACHE I think.

[RReverser]

You can override paths in the C++ extension and remap those bot paths to either local Emscripten checkout or even Github URLs

That said, it would be nice if Emscripten did this during the build using - fdebug-prefix-map.

[sbc100]

You can override paths in the C++ extension and remap those bot paths to either local Emscripten checkout or even Github URLs

That said, it would be nice if Emscripten did this during the build using - fdebug-prefix-map.

That does sounds useful.. is there already a bug about that?

[sbc100]

As @kripken says, it should not be necessary for normal users to ever run --clear-cache. This is especially true for emsdk users. If you are seeing out of day libraries then perhaps something odd is going on here. Are you using emsdk? What directory is emscirpten using for its cache? (building anything with embuilder will show this, or --clear-cache, e.g. ./embuilder build sysroot --force)

[stale[bot]]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.