Skip to content

Commit e345e85

Browse files
committed
crashdump: add documentation on how to load a guest core dump in a gdb and lldb using vscode
Signed-off-by: Doru Blânzeanu <[email protected]>
1 parent 51ce291 commit e345e85

File tree

1 file changed

+62
-4
lines changed

1 file changed

+62
-4
lines changed

docs/debugging-hyperlight.md

+62-4
Original file line numberDiff line numberDiff line change
@@ -37,11 +37,69 @@ Alternatively, this can be enabled when running a test from the command line:
3737
cargo test --package hyperlight-host --test integration_test --features print_debug -- static_stack_allocate --exact --show-output
3838
```
3939

40-
## Dumping the memory configuration, virtual processor register state and memory contents on a crash or unexpected VM Exit
41-
42-
To dump the details of the memory configuration, the virtual processors register state and the contents of the VM memory set the feature `crashdump` and run a debug build. This will result in a dump file being created in the temporary directory. The name and location of the dump file will be printed to the console and logged as an error message.
40+
## Dumping the guest state to an ELF core dump
41+
42+
To dump the state of the vCPU (general purpose registers, registers) to an `ELF` core dump file set the feature `crashdump` and run a debug build. This will result in a dump file being created in the temporary directory.
43+
The name and location of the dump file will be printed to the console and logged as an error message.
44+
45+
After the core dump has been created, to inspect the state of the guest, load the core dump file using `gdb` or `lldb`.
46+
To do this in vscode, the following configuration can be used to add debug configurations:
47+
```vscode
48+
{
49+
"version": "0.2.0",
50+
"inputs": [
51+
{
52+
"id": "core_dump",
53+
"type": "promptString",
54+
"description": "Path to the core dump file",
55+
},
56+
{
57+
"id": "program",
58+
"type": "promptString",
59+
"description": "Path to the program to debug",
60+
}
61+
],
62+
"configurations": [
63+
{
64+
"name": "[GDB] Load core dump file",
65+
"type": "cppdbg",
66+
"request": "launch",
67+
"program": "${input:program}",
68+
"coreDumpPath": "${input:core_dump}",
69+
"cwd": "${workspaceFolder}",
70+
"MIMode": "gdb",
71+
"externalConsole": false,
72+
"miDebuggerPath": "/usr/bin/gdb",
73+
"setupCommands": [
74+
{
75+
"description": "Enable pretty-printing for gdb",
76+
"text": "-enable-pretty-printing",
77+
"ignoreFailures": true
78+
},
79+
{
80+
"description": "Set Disassembly Flavor to Intel",
81+
"text": "-gdb-set disassembly-flavor intel",
82+
"ignoreFailures": true
83+
}
84+
]
85+
},
86+
{
87+
"name": "[LLDB] Load core dump file",
88+
"type": "lldb",
89+
"request": "launch",
90+
"stopOnEntry": true,
91+
"processCreateCommands": [],
92+
"targetCreateCommands": [
93+
"target create -c ${input:core_dump} ${input:program}",
94+
],
95+
},
96+
]
97+
}
98+
```
99+
NOTE: The `CodeLldb` debug session does not stop after launching. To see the code, stack frames and registers you need to
100+
press the `pause` button. This is a known issue with the `CodeLldb` extension [#1245](https://github.com/vadimcn/codelldb/issues/1245).
101+
The `cppdbg` extension works as expected and stops at the entry point of the program.
43102

44-
There are no tools at this time to analyze the dump file, but it can be useful for debugging.
45103

46104
## Debugging guests
47105

0 commit comments

Comments
 (0)