gdbstub icon indicating copy to clipboard operation
gdbstub copied to clipboard

First time using gdbstub, lldb stuck during setup

Open evmar opened this issue 2 months ago • 11 comments

I attempted to integrate gdbstub into my emulator, following the basics in the (very extensive!) docs. I sprinkled some todo!()s and logs to see which codepaths I'll need to implement next. I'm now trying to run things for the first time and things are failing silently -- lldb is hung, and I see no logs or todos.

You can see my code (mostly a cut'n'paste from the docs) here.

I tried invoking lldb via the script in the above, and here's a trace of what it prints:

$ lldb -s lldb-script 
(lldb) command source -s 0 'lldb-script'
Executing commands in '/Users/evmar/win/rs/lldb-script'.
(lldb) platform select remote-windows
  Platform: remote-windows
 Connected: no
(lldb) platform connect connect://localhost:9001
  Platform: remote-windows
  Hostname: (null)
 Connected: yes
(lldb) target create exe/winapi/winapi.exe
Current executable set to '/Users/evmar/win/rs/exe/winapi/winapi.exe' (i386).
(lldb) r

and here's what's printed in the process running gdbstub:

INFO cli/src/debugger.rs:125 Waiting for a GDB connection on "localhost:9001"...
INFO cli/src/debugger.rs:128 Debugger connected from [::1]:53464

and both print nothing further. How can I debug what lldb is attempting? Do you have docs on how you actually should connect a remote debugger for the first time, like which gdb commands to invoke?

(I suspect I may have possibly misunderstood how run_blocking is supposed to work?)

If I break my gdbstub process in a debugger (oof, debugging a process that is itself a remote debugging target, haha) it appears stuck here:

    frame #3: 0x0000000100278edc retrowin32`std::os::unix::net::datagram::UnixDatagram::recv::h0f6a339d34c3b81a at datagram.rs:385:9 [opt]
    frame #4: 0x000000010024d7d8 retrowin32`std::io::default_read_exact::h63573348629e30b8(this=0x000000016fdfcd78, buf=(data_ptr = "", length = 1)) at mod.rs:560:15
    frame #5: 0x000000010024d990 retrowin32`std::io::Read::read_exact::h43d12378c6226a36(self=0x000000016fdfcd78, buf=(data_ptr = "", length = 1)) at mod.rs:948:9
    frame #6: 0x000000010024f270 retrowin32`gdbstub::conn::impls::tcpstream::_$LT$impl$u20$gdbstub..conn..ConnectionExt$u20$for$u20$std..net..tcp..TcpStream$GT$::read::hd812327a3efb48cd(self=0x000000016fdfcd78) at tcpstream.rs:39:15
    frame #7: 0x000000010000fe98 retrowin32`gdbstub::stub::GdbStub$LT$T$C$C$GT$::run_blocking::ha03ebcdac8d4acf5(self=<unavailable>, target=0x000000016fdfd5c8) at mod.rs:170:32
    frame #8: 0x000000010002a924 retrowin32`retrowin32::debugger::main::h68b1195b63a99e9a(machine=<unavailable>) at debugger.rs:137:18

which indicates there is some protocol communication going on, but none of my code I think.

evmar avatar Jun 25 '24 17:06 evmar