[Lldb-commits] [PATCH] D96176: Implement jAttachWait

Sun Feb 7 10:48:18 PST 2021

labath added a comment.

In D96176#2547324 <https://reviews.llvm.org/D96176#2547324>, @augusto2112 wrote:

> In D96176#2546777 <https://reviews.llvm.org/D96176#2546777>, @labath wrote:
>
>> One alternative could be to just tack on some extra data to the existing vAttach family packets  (`vAttachWait;foo;interval:47;duration=74`).
>
> This was how I did it originally on https://reviews.llvm.org/D93895. @clayborg pointed out that this might not be compatible with existing lldb-server implementations, and suggested a new packet.

If we only append the extra fields when the user explicitly requests them, then I don't think this would be a compatibility issue. The way I see it, one of two things can happen in this case:
a) the server ignores the extra fields and completes the attach with the default values
b) the server balks at the packet, and returns an error
I think both of them are reasonable results and they can be fixed/worked around in the same way -- just drop the special requests...

>>> Lastly, this current implementation has a bug I couldn't figure out, where if we're sending l an error response, lldb loses connection to lldb-server (this happens even if the first thing I do in the handle_jAttachWait function is return an error)
>>
>> I'm not sure that's a bug (i.e., lldb may be intentionally dropping the connection). What would you expect lldb to do when it gets an error response?
>
> To expand on the error, if I change `handle_vAttachWait` to immediately return an error with string "foo", lldb will print out: `error: attach failed: foo`, while if I do the same on `handle_jAttachWait` if will print out: `error: attach failed: lost connection`, so we lose the error message.
>
>>> and, also, CTRL+C from lldb doesn't interrupt lldb-server. If anyone know why this might be happening, I'd be glad to hear it.
>>
>> Seems to work for me (in that I get back to the lldb prompt and the server connection is terminated), if I press ^C **twice**.
>
> What I mean is that my new packet has these problems, and `vAttachWait` doesn't. I'm confused because I believe I implemented all the parts the same as the other `vAttach` functions.

Hm.. I don't know.. I guess you'll have to step through the code to find where it diverges...

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D96176/new/

https://reviews.llvm.org/D96176