This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Make `process connect` blocking in synchronous mode.
ClosedPublic

Authored by JDevlieghere on Jul 13 2020, 3:58 PM.

Details

Summary

In synchronous mode, the process connect command and its aliases should wait for the stop event before claiming the command is complete. Currently, the stop event is always handled asynchronously by the debugger. The implementation takes the same approach as Process::ResumeSynchronous which hijacks the event and handles it on the current thread. Similarly, after this patch, the stop event is part of the command return object, which is the property used by the test case.

Most of the discussion for this patch took place in D83446

Diff Detail

Event Timeline

JDevlieghere created this revision.Jul 13 2020, 3:58 PM
JDevlieghere retitled this revision from [lldb] Make `process connect` behave correctly in synchronous mode. to [lldb] Make `process connect` blocking in synchronous mode. .Jul 13 2020, 4:04 PM

Couple of minor comments.

lldb/include/lldb/Target/Platform.h
855

Even though this is a private method it's still worth documenting the fact that you are switching off of "stream != nullptr" to determine sync vrs. async attach. That's not obvious.

lldb/source/Target/Platform.cpp
1834

If you fail here you leave the process hijacked. That doesn't matter because if "ConnectRemote" fails, you aren't going to have much to listen to anyway. But it still looks odd. I'm surprised we don't have some RAII-dingus for process hijacking, but anyway, it's good practice to undo this in the error branch.

Address Jim's feedback

JDevlieghere marked 3 inline comments as done.Jul 13 2020, 4:36 PM
JDevlieghere added inline comments.
lldb/source/Target/Platform.cpp
1834

Yeah, that's exactly my reasoning. You can't use a RAII object here, because the order of destruction is undefined, so you might end up calling RestoreProcessEvents after the shared pointer has been destructed. Anyway, I've added the call just for consistency.

jingham accepted this revision.Jul 13 2020, 4:41 PM

LGTM

This revision is now accepted and ready to land.Jul 13 2020, 4:41 PM
labath accepted this revision.Jul 14 2020, 12:51 AM

The code looks fine. The test could be cleaned up a bit...

lldb/source/Target/Platform.cpp
1834

I'm not sure what you mean by the undefined destruction order. In c++ the destruction order is always the reverse of the construction order. The only "exception" to that that I am aware of is the destruction order for function call arguments. But even there the destruction order is still reverse construction order -- just the construction order itself is not (fully) defined.

lldb/test/API/functionalities/gdb_remote_client/TestProcessConnect.py
20–44

It looks like this was copied from the "platform process list" test. I'd be very surprised if this is really needed. I guess the default responder should work just fine here...

47

s/s/ss :P

64

Besides the negative output check, it would be also good to test that the event actually gets delivered. I think something like lldbutil.expect_state_changes(self, self.dbg.GetListener(), self.process(), [lldb.eStateStopped]) ought to do the trick.

JDevlieghere marked 7 inline comments as done.Jul 14 2020, 8:33 AM
JDevlieghere added inline comments.
lldb/source/Target/Platform.cpp
1834

I was thinking of static destructors, but that is also reverse construction order, the construction order across TUs is just not defined.

lldb/test/API/functionalities/gdb_remote_client/TestProcessConnect.py
47

My attempt to sneak in some Dutch spelling failed. (/jk)

This revision was automatically updated to reflect the committed changes.
JDevlieghere marked 2 inline comments as done.
Herald added a project: Restricted Project. · View Herald TranscriptJul 14 2020, 8:45 AM