Support using the extended thread-id syntax with Hg packet to select
a subprocess. This makes it possible to start providing support for
running some of the debugger packets against another subprocesses.
Details
Diff Detail
Event Timeline
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp | ||
---|---|---|
2097 | Good question. As for PID, I don't think that the client would do something like that within foreseeable future. However, sending all-TIDs are technically supported in our LLGS client code. I don't know whether it's actually used anywhere, though. |
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp | ||
---|---|---|
2100 | Just a drive-by comment: The previous behaviour was to send 0x15 when the current process ID was invalid. Should we do that here? |
I'm probably not the most qualified to sign off on this, but the review has stalled and I don't see anything obviously wrong here so LGTM.
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp | ||
---|---|---|
2091 | Would it be useful to say "Malformed thread-id for process-id {}"? |
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp | ||
---|---|---|
2091 | In this context, 'thread-id' is GDB protocol jargon for 'PID and/or TID'. So if it's malformed, then we don't really have a process ID here. I suppose I could try replacing 'thread-id' with something more verbose but I'm not sure if this is the kind of error end users will be dealing with. |
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp | ||
---|---|---|
2091 | Fair enough. Thanks for the explanation! |
revert