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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
