Dwarf tests fail on windows due to path seperators

[sbc100]

I noticed this when enabling windows testing as part of CI for the time in #2646.

--- D:\a\binaryen\binaryen\test\passes\class_with_dwarf_noprint.bin.txt
+++ actual
@@ -180,7 +180,7 @@
                 DW_AT_name [DW_FORM_strp]	( .debug_str[0x000000e5] = "rng1")
                 DW_AT_type [DW_FORM_ref4]	(cu + 0x0037 => {0x00000037} "Random")
                 DW_AT_external [DW_FORM_flag_present]	(true)
-                DW_AT_decl_file [DW_FORM_data1]	("/tmp/emscripten_test_wasm3_2u9tontv/src.cpp")
+                DW_AT_decl_file [DW_FORM_data1]	("/tmp/emscripten_test_wasm3_2u9tontv\src.cpp")
                 DW_AT_decl_line [DW_FORM_data1]	(23)
                 DW_AT_location [DW_FORM_exprloc]	(DW_OP_addr 0x638)

May be worth fixing.. maybe not.

[kripken]

Interesting, I guess this means the LLVM code emits windows-style slashes on windows, and our testcase has hardcoded POSIX-style ones.

I wonder if we should maybe make it always emit POSIX-style ones? Or make the test runner accept multiple possible inputs?

[kripken]

Note from #2965, once this is fixed we can enable windows testing on CI.

[RReverser]

Or make the test runner accept multiple possible inputs?

Could the test runner use os.path.normpath?

[sbc100]

I think the test runner compares the entire contents of the generated output.. it doesn't know if a given output file contains any pathnames or where they are .

I guess we should think about what the expected behavior is here. The problem occurs when binaryen reads dwarf information that already contains a certain pathname style but the fails to use that style when writing that output. Could we set the preferred style based on the input file maybe?

[sbc100]

I'm not even sure why binaryen is re-creating pathnames in the dwarf info, alon do you know the codepath that is doing this? Should it not just use the exact same paths that were in the input file?

[kripken]

Correct, the test runner just runs wasm-opt --dwarfdump which dumps a lot of info, including paths. It doesn't know which parts of that large text are path names.

I'm not sure exactly what in the LLVM code is doing this. I hoped to debug it using the PR, however CI fails on a previous windows-specific failure, so I didn't get that far yet.