Cannot attach to GDB server of QEMU for riscv64

[trmckay]

OS: macOS Monterey 12.5
VSCode version: 1.70.1
CodeLLDB version: 1.7.4
Compiler: rustc nightly and gcc 11.1.0
Debuggee: riscv64-unknown-none-elf on QEMU riscv64-virt 7.0.0

Cannot attach to remote GDB server of QEMU. The connection is made successfully, but the extension crashes shortly after. The debugger is left appearing as though it is still trying to attach.

Verbose log

Initial debug configuration: {
  name: 'Attach to debug server',
  type: 'lldb',
  request: 'custom',
  targetCreateCommands: [ 'target create ${workspaceFolder}/build/halogen-test.elf' ],
  initCommands: [ 'gdb-remote localhost:1234' ],
  __configurationTarget: 6
}
Resolved debug configuration: {
  name: 'Attach to debug server',
  type: 'lldb',
  request: 'launch',
  targetCreateCommands: [ 'target create ${workspaceFolder}/build/halogen-test.elf' ],
  initCommands: [ 'gdb-remote localhost:1234' ],
  __configurationTarget: 6,
  custom: true,
  relativePathBase: '/Volumes/Code/halogen',
  _adapterSettings: {
    displayFormat: 'auto',
    showDisassembly: 'auto',
    dereferencePointers: true,
    suppressMissingSourceFiles: true,
    evaluationTimeout: 5,
    consoleMode: 'commands',
    sourceLanguages: null,
    terminalPromptClear: null,
    evaluateForHovers: true,
    commandCompletions: true,
    reproducer: false
  }
}
liblldb: /Users/tmckay/.vscode/extensions/vadimcn.vscode-lldb-1.7.4/lldb/lib/liblldb.dylib
environment: {}
params: { evaluateForHovers: true, commandCompletions: true }
[2022-08-14T17:42:55.701Z DEBUG codelldb] New debug session
[2022-08-14T17:42:55.802Z DEBUG codelldb::dap_codec] --> {"command":"initialize","arguments":{"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"lldb","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-us","supportsProgressReporting":true,"supportsInvalidatedEvent":true,"supportsMemoryReferences":true,"supportsArgsCanBeInterpretedByShell":true},"type":"request","seq":1}
[2022-08-14T17:42:55.803Z DEBUG codelldb::dap_codec] <-- {"seq":1,"type":"response","request_seq":1,"success":true,"command":"initialize","body":{"exceptionBreakpointFilters":[{"default":true,"filter":"cpp_throw","label":"C++: on throw"},{"default":false,"filter":"cpp_catch","label":"C++: on catch"}],"supportTerminateDebuggee":true,"supportsCancelRequest":true,"supportsCompletionsRequest":true,"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":true,"supportsDataBreakpoints":true,"supportsDelayedStackTraceLoading":true,"supportsEvaluateForHovers":true,"supportsFunctionBreakpoints":true,"supportsGotoTargetsRequest":true,"supportsHitConditionalBreakpoints":true,"supportsLogPoints":true,"supportsReadMemoryRequest":true,"supportsRestartFrame":true,"supportsSetVariable":true,"supportsWriteMemoryRequest":true}}
[2022-08-14T17:42:55.812Z DEBUG codelldb::dap_codec] --> {"command":"launch","arguments":{"name":"Attach to debug server","type":"lldb","request":"launch","targetCreateCommands":["target create /Volumes/Code/halogen/build/halogen-test.elf"],"initCommands":["gdb-remote localhost:1234"],"__configurationTarget":6,"custom":true,"relativePathBase":"/Volumes/Code/halogen","_adapterSettings":{"displayFormat":"auto","showDisassembly":"auto","dereferencePointers":true,"suppressMissingSourceFiles":true,"evaluationTimeout":5,"consoleMode":"commands","sourceLanguages":null,"terminalPromptClear":null,"evaluateForHovers":true,"commandCompletions":true,"reproducer":false},"__sessionId":"02ca7a55-ce0b-4d5f-9b0e-8351a0c6a76c"},"type":"request","seq":2}
[2022-08-14T17:42:55.812Z DEBUG codelldb::dap_codec] <-- {"seq":2,"type":"event","event":"output","body":{"output":"Console is in 'commands' mode, prefix expressions with '?'.\n"}}
[2022-08-14T17:42:55.812Z DEBUG codelldb::dap_codec] <-- {"seq":3,"type":"event","event":"output","body":{"output":"Executing script: initCommands\n"}}
[2022-08-14T17:42:55.818Z DEBUG codelldb::debug_session] gdb-remote localhost:1234 -> SuccessFinishNoResult, Error:  Success
INFO(Python) 10:42:55 formatters: Initializing
INFO(Python) 10:42:55 formatters.rust: Initializing
[2022-08-14T17:42:55.823Z DEBUG codelldb::dap_codec] <-- {"seq":4,"type":"event","event":"output","body":{"output":"Executing script: targetCreateCommands\n"}}
[2022-08-14T17:42:55.847Z DEBUG codelldb::debug_session] target create /Volumes/Code/halogen/build/halogen-test.elf -> SuccessFinishNoResult, Error:  Success
    Output Message:
    Current executable set to '/Volumes/Code/halogen/build/halogen-test.elf' (riscv64).
[2022-08-14T17:42:55.847Z DEBUG codelldb::dap_codec] <-- {"seq":5,"type":"event","event":"output","body":{"output":"Current executable set to '/Volumes/Code/halogen/build/halogen-test.elf' (riscv64).\n\n"}}

[2022-08-14T17:42:55.847Z DEBUG codelldb::debug_session] Debug event: 0x14e630410 Event: broadcaster = 0x15080a850 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x15080a818 (pid = 1), state = stopped}

[2022-08-14T17:42:55.847Z DEBUG codelldb::dap_codec] <-- {"seq":6,"type":"event","event":"initialized"}

thread '' panicked at 'Whoops! Something that was supposed to have been initialized at this point, wasn't.', adapter/src/debug_session.rs:1812:31

note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

[2022-08-14T17:42:55.851Z DEBUG codelldb::dap_codec] --> {"command":"setBreakpoints","arguments":{"source":{"name":"main.rs","path":"/Volumes/Code/halogen/halogen/kernel/src/main.rs"},"lines":[86,91],"breakpoints":[{"line":86},{"line":91}],"sourceModified":false},"type":"request","seq":3}

[2022-08-14T17:42:55.851Z ERROR codelldb::debug_session] channel closed

[vadimcn]

Looks like QEmu is sending a "process stopped" notification while CodeLLDB has not yet registered that a process exists.
Can you tell me more about you debugging target? Is there an easy way to reproduce your setup?

[trmckay]

I'm attaching to this QEMU machine.

I'm trying to set up VSCode for one of my projects. If you want to recreate my setup, you can clone this repo. I've provided a codelldb-debug branch with .vscode checked in.

I also have a Docker container for building, so you shouldn't need a RISC-V toolchain (pull from trmckay/rust-riscv or build from the docker directory). You can run

docker run -it --rm  -v "$(pwd):/src" -p "1234:1234" trmckay/rust-riscv python3 build.py debug_server

and it will build the project and launch it in QEMU with a GDB server. You may have to use host networking or play with the task.json to get the right hostname of the container. Also C-a x will quit QEMU.

I'd say do the Docker stuff in a terminal, then try to attach with the provided launch.json. Let me know if I can help any more.

[vadimcn]

Thanks. How can I keep container running? Kinda annoying that it rebuilds everything after each debug session.
Edit: doesn't actually rebuid, but re-downloads rust components and dependent crates...

[trmckay]

Thanks. How can I keep container running? Kinda annoying that it rebuilds everything after each debug session. Edit: doesn't actually rebuid, but re-downloads rust components and dependent crates...

I can think of two ways.

1. Run the container with bash instead of python3, then run the build script from the shell as many times as you want.
2. Create a directory or Docker volume and mount it into the container at /root/.cargo so the toolchain and dependencies persist after the container exits.

[vadimcn]

gdb-remote localhost:1234' should go into processCreateCommands, not initCommands. With that change, codelldb attaches successfully, but I don't think it can parse the debuggee state.

[trmckay]

One thing that could be relevant: at attach, the memory-map does not correspond with the ELF. Eventually does, but not right away.

Not sure if cross-arch debugging QEMU is something you intend to support. It seems like this could be a nightmare to maintain for all the different setups.

[vadimcn]

Not sure if cross-arch debugging QEMU is something you intend to support. It seems like this could be a nightmare to maintain for all the different setups.

It is mostly up to LLDB to support such scenarios. I've created the "custom launch" mode specifically to enable debugging various oddball targets, which don't fit into the normal launch/attach cases, but that's where I draw the line.

This seems relevant to the failure I am seeing in your case: llvm/llvm-project#49285