Fix parsing of dwarfdump output to be more resilient

[kon72]

To generate source maps, we run llvm-dwarfdump against wasm file and parse its plain-text output heavily relied on regex matches.
Previously, in order to retrieve comp dir from debug_info section, we search regex patterns assuming that the output has entries DW_AT_stmt_list and DW_AT_comp_dir consecutively in this order, but I noticed that assumption doesn't hold in some cases.

The output that the previous code can parse comp_dir successfully:

0x00007a49: DW_TAG_compile_unit
              DW_AT_producer    ("clang version 18.0.0 (https://github.com/llvm/llvm-project 269685545e439ad050b67740533c59f965cae955)")
              DW_AT_language    (DW_LANG_C99)
              DW_AT_name    ("../../../system/lib/libc/musl/src/stdio/fflush.c")
              DW_AT_stmt_list   (0x00005c46)
              DW_AT_comp_dir    ("/emsdk/emscripten/cache/build/libc-debug-tmp")
              DW_AT_low_pc  (0x00002902)
              DW_AT_high_pc (0x00002a40)

The output that the previous code fails to parse comp_dir:

0x00007ddd: DW_TAG_compile_unit
              DW_AT_stmt_list   (0x00005f56)
              DW_AT_ranges  (0x000006b0
                 [0x00002c46, 0x00002c4e)
                 [0x00002c4f, 0x00002c59)
                 [0x00002c5a, 0x00002c74)
                 [0x00002c75, 0x00002c7d))
              DW_AT_name    ("../../../system/lib/compiler-rt/stack_ops.S")
              DW_AT_comp_dir    ("/emsdk/emscripten/cache/build/libcompiler_rt-tmp")
              DW_AT_producer    ("clang version 18.0.0 (https://github.com/llvm/llvm-project 269685545e439ad050b67740533c59f965cae955)")
              DW_AT_language    (DW_LANG_Mips_Assembler)

With this change, it can parse comp_dir regardless of the order of DW_* entries

[sbc100]

Unrelated to this PR, but it looks like these two lines can be written as:

  for stmt_list in debug_line_chunks[1::2]:

[kon72]

Ok, I included this change in the PR.

[dschuff]

overall this looks right to me.
@sbc100 should the minimal_runtime test failures go away with a rebase?

[dschuff]

since it doesn't parse all the debug info contents (and since "debug info" is a bit ambiguous in this context since it could mean debug info generally or the specific .debug_info section), maybe this function could be called something that indicates that it extracts comp_dir information (e.g. "extract_comp_dir_map" or something like that).

[kon72]

Done. Renamed to extract_comp_dir_map

[dschuff]

One other request: if this is your first contribution, please add yourself to the AUTHORS file.

[kripken]

@dschuff We recently found that adding to AUTHORS is optional,

emscripten/AUTHORS

Lines 1 to 7 in f9f6f13

	Contributors to Emscripten may optionally add themselves to this list of
	authors if they choose to do so. This is optional because the git history is
	good enough for that purpose, and in fact most projects do not maintain such a
	manual list.
	While the file is not necessary, to preserve the history of the project we are
	not removing it.

So in general it is fine to either add to it, or not.

Separately, would it be practical to add testing in this PR? I commented in one of the related PRs here: #20776 (comment) But if it would be simpler to test this after those PRs that's find of course.

[kon72]

@kripken

So in general it is fine to either add to it, or not.

Anyway, I added myself to AUTHORS :)

Separately, would it be practical to add testing in this PR?

I added a test but I have one question:
Since wasm-sourcemap.py has a dash - in its file name, I couldn't import it with a normal import statement, which I resort to use importlib.import_module.
Should I rename wasm-sourcemap.py to wasm_sourcemap.py so we can simply import it? or should I test it by running wasm-sourcemap.py as an executable so we don't have to import it? or is it good to go with current test code?

[kripken]

Perhaps move this into the test itself? But, if it is simpler to run it as an executable, that seems fine as well.

[kon72]

Moved import_module into the test.

[dschuff]

IIUC running it as an executable is consistent with how most of these auxiliary scripts are executed. It might be more optimal to do a broader change there, but I think keeping consistent here is fine.

[kripken]

Thanks for these fixes @kon72 !