This is an archive of the discontinued LLVM Phabricator instance.

Remote Non-Stop Support
ClosedPublic

Authored by EwanCrawford on May 11 2015, 4:57 AM.

Details

Summary

This patch is the beginnings of support for Non-stop mode in the remote protocol. Letting a user examine stopped threads, while other threads execute freely.

Non-stop mode is enabled using the setting target.non-stop-mode, which sends a QNonStop packet when establishing the remote connection.
Changes are also made to treat the '?' stop reply packet differently in non-stop mode, according to spec https://sourceware.org/gdb/current/onlinedocs/gdb/Remote-Non_002dStop.html#Remote-Non_002dStop.
A setting for querying the remote for default thread on setup is also included.

Handling of '%' async notification packets will be added next.

Diff Detail

Repository
rL LLVM

Event Timeline

EwanCrawford retitled this revision from to Remote Non-Stop Support.
EwanCrawford updated this object.
EwanCrawford edited the test plan for this revision. (Show Details)
EwanCrawford added a reviewer: clayborg.
EwanCrawford set the repository for this revision to rL LLVM.
EwanCrawford added subscribers: Unknown Object (MLST), deepak2427, ted, ADodds.
clayborg edited edge metadata.May 11 2015, 10:17 AM

Everything looks good. Just one quests on why we need the "default-thread" setting. Can you explain why we need a user settable setting here? Shouldn't we just do this if non stop mode is enabled?

source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
111 ↗(On Diff #25458)

Why do we need a setting for this? Why would anyone want to set this manually? It would be great to not require this and just "do the right thing". Please explain why this is needed.

EwanCrawford edited edge metadata.

Thanks for having a look Greg. I removed the setting so that we only query for a default thread when non stop mode is enabled.

clayborg accepted this revision.May 12 2015, 10:31 AM
clayborg edited edge metadata.

As long as default mode still works, this looks good.

This revision is now accepted and ready to land.May 12 2015, 10:31 AM
This revision was automatically updated to reflect the committed changes.

This patch seems okay for what it does, but there are a bunch of places where the stepping machinery assumes that it can stop all the threads to do things like stepping over breakpoints, etc. You are going to get lots of subtle funny behavior - like missing breakpoint hits on live threads when stepping over the breakpoint hit on another thread, or getting confused if a live thread hits a breakpoint when we think we are only running one thread for some other purpose. That part is going to take a bit more thought to get it to work correctly. This needs to be designed...