Fix debug-compilation-dir for system libs

[kon72]

Fixes #20775

Before this change:

$ llvm-dwarfdump -debug-info -debug-line --recurse-depth=0  emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a
...
              DW_AT_name    ("../../../system/lib/compiler-rt/__trap.c")
              DW_AT_comp_dir    ("/emsdk/emscripten")

After this change:

$ llvm-dwarfdump -debug-info -debug-line --recurse-depth=0  emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a
...
              DW_AT_name    ("../../../system/lib/compiler-rt/__trap.c")
              DW_AT_comp_dir    ("/emsdk/emscripten/cache/build/libcompiler_rt-tmp")

[RReverser]

Good catch! It's worth adding a test for this in test_other.py too.

[sbc100]

This seems like maybe the wrong fix.

I think the mapping on the line about is the one that needs updating so it ends up being something like -ffile-prefix-map=../..=/emsdk/emscripten'. I think the best way would be to replace source_dir` with somekind of relative source dir?

[kon72]

You mean that the DWARF entries should be like this?

DW_AT_name    ("/emsdk/emscripten/system/lib/compiler-rt/__trap.c")
DW_AT_comp_dir    ("/emsdk/emscripten")

I agree with your direction so that unnecessary build sub directories (like cache/build/libcompiler_rt-tmp) would be stripped out from dwarf info.

[kripken]

Regarding testing, maybe checking the contents of dwarfdump is simplest, like e.g. test_separate_dwarf does:

emscripten/test/test_other.py

Lines 9713 to 9720 in cfc68d8

	# Check that dwarfdump can dump the debug info
	dwdump = self.run_process(
	[LLVM_DWARFDUMP, 'subdir/output.wasm.debug.wasm', '-name', 'main'],
	stdout=PIPE).stdout
	# Basic check that the debug info is more than a skeleton. If so it will
	# have a subprogram descriptor for main
	self.assertIn('DW_TAG_subprogram', dwdump)
	self.assertIn('DW_AT_name\t("main")', dwdump)

[sbc100]

Can you mark this new test a @crossplatform so it runs on mac and windows too?

[kon72]

Sure.

[kon72]

It looks the test is failing on Windows due to path separators (could be related to WebAssembly/binaryen#2781)

From CI output:

DW_AT_name\t("system\\\\lib/emmalloc.c")
DW_AT_comp_dir\t("/emsdk/emscripten")

@sbc100
Should we modify the test to make it pass on Windows? or drop @crossplatform?

[sbc100]

I think it would be good to fix if possible. Perhaps if this is a pre-existing issue maybe we don't have to fix it now, but it would be good to fix if possible.

Any idea how system\\\\lib/emmalloc.c could end up like that?

[kon72]

After some digging on my local Windows machine, It seems backslashes in system\\\\lib/emmalloc.c are coming from the source file path we're passing to Clang, and the slash before basename is due to -ffile-reproducible.

Currently, embuilder is passing the source file path in the platform-specific format (with backslashes as separators on Windows):

clang.exe <redacted> -c ..\..\..\system\lib\emmalloc.c

and I get the following DWARF entry

DW_AT_name ("system\\lib/emmalloc.c")

Then when I replace backslashes in the source file path with slashes, the DWARF also have slashes in its file names.

clang.exe <redacted> -c ../../../system/lib/emmalloc.c
DW_AT_name ("system/lib/emmalloc.c")

Therefore, I think the best approach is to apply utils.normalize_path to source file names in the build command.
What do you think?

[kripken]

That looks right to me.

[sbc100]

Looks like you need to add these lines to the new test:

    if config.FROZEN_CACHE:                                                                          
      self.skipTest("test doesn't work with frozen cache")  

[kripken]

That looks right to me.