-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Debugging module with lldb shows local variables as not available #3884
Comments
It looks like the
( |
Based on #842 it was supported at some time. Missing tests though because format was evolving on LLVM side. |
Getting the same issue on lldb 12.0.1 |
Any updates about this issue? |
To quote @cfallin from #4669 (comment) (which is another debuginfo issue):
|
I have tried the simple C code above the issue and the issue no longer reproduces. However, I have a larger example (not yet in C/C++) that does show bad behavior with local variables. We start with: public static int Main()
{
SimpleStruct simpleStruct = new() { IntField = 1, FloatField = 2.0f };
SimpleClass simpleClass = new() { IntField = 1, FloatField = 2.0f };
TestBasicTypesDisplay(true, false, 'a', 1, -1, 2, -2, 3, -3, 4, -4, 5, -5, 1.0f, 2.0);
TestEnumDisplay(DayOfWeek.Monday);
TestByRefDisplay(ref simpleStruct, ref simpleClass);
TestPointerDisplay(&simpleStruct);
TestStringDisplay("Basic string");
TestBasicArrayDisplay(new int[] { 1, 2, 3 }, new double[] { 1, 2, 3 });
TestComplexArrayDisplay(new[] { simpleClass }, new[] { simpleStruct });
TestBasicMultiDimensionalArrayDisplay(new int[,] { { 1, 2, 3 }, { 4, 5, 6 } });
TestSimpleStructDisplay(simpleStruct);
TestSimpleClassDisplay(simpleClass);
TestDerivedClassDisplay(new() { IntField = 1, FloatField = 2.0f, LongField = 3 });
TestRecursiveClassDisplay(new() { Value = 1, Next = new() { Value = 2 } });
simpleStruct.TestStructInstanceMethod();
simpleClass.TestClassInstanceMethod();
TestVariables(5, simpleStruct, simpleClass);
return 100;
} We have this DWARF for the generated WASM: 0x0011c6f2: DW_TAG_subprogram
DW_AT_low_pc (0x004d9992)
DW_AT_high_pc (0x004daf32)
DW_AT_frame_base (DW_OP_WASM_location 0x0 0x3, DW_OP_stack_value)
DW_AT_linkage_name ("WasmDebugging_Program__Main")
DW_AT_name ("Main")
DW_AT_decl_file ("C:\Users\Accretion\source\dotnet\runtimelab\src\tests\nativeaot\SmokeTests\HelloWasm\WasmDebugging.cs")
DW_AT_decl_line (15)
DW_AT_type (0x000000000010c1b2 "int")
0x0011c70e: DW_TAG_variable
DW_AT_location (DW_OP_fbreg +0x58)
DW_AT_name ("simpleStruct")
DW_AT_type (0x0011c72d "WasmDebugging_SimpleStruct")
0x0011c71b: DW_TAG_variable
DW_AT_location (DW_OP_fbreg +0x4, DW_OP_deref, DW_OP_plus_uconst 0x0)
DW_AT_name ("simpleClass")
DW_AT_type (0x0011c748 "WasmDebugging_SimpleClass &") Pretty standard/expected. I compiled this with We get (with offsets for location lists for better legibility):
Observations:
|
I think I see what is going here quite clearly now. During DWARF translation, actual as-reported-by-the-code-generator live ranges of "value labels" (side note: quite the confusing name for what are actually simply WASM locals) are intersected with the ranges in the WASM DWARF. So for a composite |
Test Case
test.wasm.zip
compiled with:
wasi-sdk-14.0/bin/clang -g -O0 test.c -o test.wasm
Steps to Reproduce
Expected Results
Running
fr v
in lldb in this context should display:Actual Results
Versions and Environment
Wasmtime version or commit: 0.34.0
Operating system: MacOS Monterrey (12.2.1)
Architecture: arm64
Extra Info
LLDB version:
This is what happens when I try to compile and run natively to show what I'm expecting:
The text was updated successfully, but these errors were encountered: