C++ related issues in dwarf_extractor.cpp

[yamt]

when compiling a C++ module, in lldb_function_to_function_dbi,

• function_args doesn't seem to include the "this" pointer. on the other hand, variable_list contains it. it causes the "function args number dismatch" message and then ParamType overrun, which likely involves a crash. a workaround: lldb_function_to_function_dbi: a hack to avoid crashing on C++ methods #3190
• variable.GetName() seems to return NULL for unnamed arg. it causes a NULL dereference. a suggested fix: lldb_function_to_function_dbi: fix a null dereference #3189 merged
• sometimes LLVMCountParams(func_ctx->func) doesn't match what's in variable_list. (variable_list has more.) usually it causes a crash in LLVMDIBuilderInsertDbgValueAtEnd. see the attached d.tgz for an example. (also, it seems that something similar happens with rust: AOT debugging setup doesn't work #3163) i guess we can investigate DW_AT_location (DW_OP_WASM_location) of variables to find the corresponding func_ctx->func's parameters. (locals) but i don't know how it can be done with the LLDB API.
  • note: clang omits empty class from low level function parameters: https://github.com/llvm/llvm-project/blob/cad6ad2759a782c48193f83886488dacc9f330e3/clang/lib/CodeGen/Targets/WebAssembly.cpp#L107-L109. (ie. it's a part of C++ ABI clang uses for this target.) in that case, in dwarf, the omitted parameter is represented as DW_TAG_formal_parameter without DW_AT_location.

d.tgz

[yamt]

btw, i wonder why dwarf_extractor.cpp uses the LLDB API, rather than, say, llvm/DebugInfo/DWARF/ api.
@wenyongh do you remember?

[wenyongh]

btw, i wonder why dwarf_extractor.cpp uses the LLDB API, rather than, say, llvm/DebugInfo/DWARF/ api. @wenyongh do you remember?

The source debugger feature was implemented by Ant group long time ago, I just cannot remember the details now. Maybe the LLDB API provides more capability?

[yamt]

a quick research on how other projects are reading the dwarf section in wasm:

binaryen: llvm DWARFContext https://github.com/WebAssembly/binaryen/blob/d6c5e4ab15df271521df7b35665c7463b2c490ca/src/wasm/wasm-debug.cpp#L96-L116

cranelift: https://github.com/gimli-rs/gimli (something written in rust)

[TianlongLiang]

It seems that AOT debugging now only has limited functionality. It was aimed to support C first It hardly covers any additional C++ features. Thus the current function-to-function debug symbol mapping only supports C styles function. And I think that's why it error when it comes to Cpp compiled wasm or Rust compiled wasm

[yamt]

It seems that AOT debugging now only has limited functionality. It was aimed to support C first It hardly covers any additional C++ features. Thus the current function-to-function debug symbol mapping only supports C styles function. And I think that's why it error when it comes to Cpp compiled wasm or Rust compiled wasm

i agree.

i tend to think a fix involves a major surgery like switching from lldb api to llvm api to read dwarf. how do you think?

[TianlongLiang]

I think it's feasible, but as you said it would be non-trivial changes. BTW, besides the extractor, will there also be some major modifications for code emission and file generation?

[yamt]

I think it's feasible, but as you said it would be non-trivial changes. BTW, besides the extractor, will there also be some major modifications for code emission and file generation?

i guess it will be mostly contained in dwarf_extractor.cpp.

[TianlongLiang]

i guess it will be mostly contained in dwarf_extractor.cpp.

Got it, thanks