jasonmolenda wrote: > I also thought the other PR looked fine and @jasonmolenda realised it wasn't
for the record, I thought it wasn't right by claude pointed out that there was a codepath I didn't see that handled that correctly already. :) We did get a new test case out of it for a notification in one Read, and the real packet in a second Read, where the tests before that were Notification+Real packet in a single Read. But yeah, the problem is that lldb can receive a single packet with a Read(), it can receive multiple packets with a Read(), or we can probably receive parts of a packet in a Read(), I'm not sure I've seen it but I wouldn't be surprised. The packet receiving code appends everything it Reads into a byte buffer and then looks for a complete packet, then returns that. The gdb remote serial protocol is such a slow back-and-forth series of communications that none of this happens often, but it is possible. Corrupt packets are all but unheard of (I can't remember ever seeing one with modern devices & communication channels), when we're not literally talking over a serial cable to an embedded board. https://github.com/llvm/llvm-project/pull/204788 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
