[Lldb-commits] [PATCH] D42195: [lldb] Generic base for testing gdb-remote behavior

[Owen Shaw via Phabricator via lldb-commits]

owenpshaw added inline comments.


================
Comment at: lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/gdbclientutils.py:335-337
+            # However, if we aren't expecting an ack, it's likely the initial
+            # ack that lldb client sends, and observations of real servers
+            # suggest we're supposed to ack back.
----------------
labath wrote:
> Which servers were you observing here? I tried lldb-server and gdbserver and they don't send the ack back (It seems like a bad idea anyway, as it could lead to an infinite ack ping-pong).
> 
> I have removed this code as it was causing flakyness on the bots. If there is a server that does this, and we care about supporting it, then we can add a new targeted test which emulates this behavior, but then we need to also fix the client to handle this situation better.
Just took another look and I misunderstood what was going on.  The server does send an opening +, but not in response to the client.

I was observing the packets from openocd, where lldb sends a + and then receives a + from openocd, and assumed one was a response to the other.

```
(lldb) log enable gdb-remote packets
(lldb) gdb-remote 3333
                 <   1> send packet: +
                 history[1] tid=0x0307 <   1> send packet: +
                 <   1> read packet: +
                 <  19> send packet: $QStartNoAckMode#b0
                 <   1> read packet: +
                 <   6> read packet: $OK#9a
                 <   1> send packet: +

```

Can't find any docs about these opening acks, but looking at openocd code, it just always sends a + at the start of a connection.  Should the test server do the same?



Repository:
  rL LLVM

https://reviews.llvm.org/D42195