================ @@ -258,3 +263,302 @@ then ``lldb B`` to trigger ``lldb-server B`` to go into that code and hit the breakpoint. ``lldb-server A`` is only here to let us debug ``lldb-server B`` remotely. +Debugging The Remote Protocol +----------------------------- + +LLDB mostly follows the `GDB Remote Protocol <https://sourceware.org/gdb/onlinedocs/gdb/Remote-Protocol.html>`_ +. Where there are differences it tries to handle both LLDB and GDB behaviour. + +LLDB does have extensions to the protocol which are documented in +`lldb-gdb-remote.txt <https://github.com/llvm/llvm-project/blob/main/lldb/docs/lldb-gdb-remote.txt>`_ +and `lldb/docs/lldb-platform-packets.txt <https://github.com/llvm/llvm-project/blob/main/lldb/docs/lldb-platform-packets.txt>`_. + +Logging Packets +*************** + +If you just want to observe packets, you can enable the ``gdb-remote packets`` +log channel. + +:: + + (lldb) log enable gdb-remote packets + (lldb) run + lldb < 1> send packet: + + lldb history[1] tid=0x264bfd < 1> send packet: + + lldb < 19> send packet: $QStartNoAckMode#b0 + lldb < 1> read packet: + + +You can do this on the ``lldb-server`` end as well by passing the option +``--log-channels "gdb-remote packets"``. Then you'll see both sides of the +connection. + +Some packets may be printed in a nicer way than others. For example XML packets +will print the literal XML, some binary packets may be decoded. Others will just +be printed unmodified. So do check what format you expect, a common one is hex +encoded bytes. + +You can enable this logging even when you are connecting to an ``lldb-server`` +in platform mode, this protocol is used for that too. + +Debugging Packet Exchanges +************************** + +Say you want to make ``lldb`` send a packet to ``lldb-server``, then debug +how the latter builds its response. Maybe even see how ``lldb`` handles it once +it's sent back. + +That all takes time, so LLDB will likely time out and think the remote has gone +away. You can change the ``plugin.process.gdb-remote.packet-timeout`` setting +to prevent this. + +Here's an example, first we'll start an ``lldb-server`` being debugged by +``lldb``. Placing a breakpoint on a packet handler we know will be hit once +another ``lldb`` connects. + +:: + + $ lldb -- lldb-server gdbserver :1234 -- /tmp/test.o + <...> + (lldb) b GDBRemoteCommunicationServerCommon::Handle_qSupported + Breakpoint 1: where = <...> + (lldb) run + <...> + +Next we connect another ``lldb`` to this, with a timeout of 5 minutes: + +:: + + $ lldb /tmp/test.o + <...> + (lldb) settings set plugin.process.gdb-remote.packet-timeout 300 + (lldb) gdb-remote 1234 + +Doing so triggers the breakpoint in ``lldb-server``, bringing us back into +``lldb``. Now we've got 5 minutes to do whatever we need before LLDB decides +the connection has failed. + +:: + + * thread #1, name = 'lldb-server', stop reason = breakpoint 1.1 + frame #0: 0x0000aaaaaacc6848 lldb-server<...> + lldb-server`lldb_private::process_gdb_remote::GDBRemoteCommunicationServerCommon::Handle_qSupported: + -> 0xaaaaaacc6848 <+0>: sub sp, sp, #0xc0 + <...> + (lldb) + +Once you're done simply ``continue`` the ``lldb-server``. Back in the other +``lldb``, the connection process will continue as normal. + +:: + + Process 2510266 stopped + * thread #1, name = 'test.o', stop reason = signal SIGSTOP + frame #0: 0x0000fffff7fcd100 ld-2.31.so`_start + ld-2.31.so`_start: + -> 0xfffff7fcd100 <+0>: mov x0, sp + <...> + (lldb) + +Reducing Bugs +------------- + +This section covers reducing a bug that happens in LLDB itself, or where you +suspect that LLDB causes something else to behave abnormaly. ---------------- DavidSpickett wrote:
Done. https://github.com/llvm/llvm-project/pull/65635 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
