[RFC/WIP] GDB support for replay diversions#2877
Draft
Bob131 wants to merge 3 commits intorr-debugger:masterfrom
Draft
[RFC/WIP] GDB support for replay diversions#2877Bob131 wants to merge 3 commits intorr-debugger:masterfrom
Bob131 wants to merge 3 commits intorr-debugger:masterfrom
Conversation
Updates the test harness to use $REPLAY_ARGS as additional arguments to 'rr replay'.
This commit adds support for the vReplayDiversion extension to the GDB remote protocol. This protocol extension moves control over diversion sessions to GDB, allowing it to explicitly model diversion state when considering things like UI heuristics or scheduling decisions, expose such state to end users and scripts, or make various aspects user-configurable. The benefit to rr in the future will be a smoothing out of several UI wrinkles and (perhaps eventually) the removal of some of the hackier, more ad-hoc parts of the rr/GDB interface. Some of these benefits will be had in the immediate-term; however, this will also come with some regressions until GDB all of the logic needed for feature-parity. (An instance of this is apparent in the number of test cases no longer passing due to this commit; GDB having control over diversion entrance/exit means rr commands can no longer trigger a diversion exit themselves. A future commit will have these commands present an error to the user instead of corrupting state, but this may well still present a regression to some users.)
If the client GDB supports the vReplayDiversion protocol extension then diversion sessions are controlled explicitly by the client; allowing rr commands to end a diversion session under GDB's nose will corrupt the implicit shared state. This commit modifies the command handler to instead present an error message to the user if a command wanted to end a GDB-requested diversion.
Collaborator
|
Those sound good too but yes, please make them separate issues. |
Contributor
@Bob131 Was there a proposal sent to gdb-patches@sourceware.org? I did not found any mention of |
Contributor
Author
|
On Wed, Mar 16, 2022 at 09:45:55 -0700, Simon Sobisch wrote:
@Bob131 Was there a proposal sent to
***@***.******@***.***)?
There was indeed; see
https://sourceware.org/pipermail/gdb-patches/2021-June/179432.html. I
never got much in the way of feedback, though, and ultimately forgot
about it.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I've been thinking about some of the awkwardness that currently exists around diversions: scheduling issues touched on in #2840, hidden state confusing GDB (e.g. #2867) and users (e.g. #1968) and the hacks and heuristics involved in trying to determine when diversion sessions should be set up/torn down. These problems aren't intractable, but it seems like they'll continue to crop up until GDB gains explicit support for a notion similar to that of rr's diversion session.
This patchset implements a (yet to be) proposed extension to the GDB remote protocol that would move control over diversion state out of rr and into GDB. The protocol introduces a new protocol feature and packet:
vReplayDiversion. GDB can sendvReplayDiversion:1to request a switch to a diversion session, andvReplayDiversion:0to end a diversion session. rr may additionally notify GDB of a premature diversion session exit by sending an inferior-exit stop packet. The GDB-side implementation mimics rr's logic (vReplayDiversion:1on inferior call,vReplayDiversion:0oncontinue) but could have commands likereplay-diversion {enter,exit}in the future.I've not yet submitted my proposal to the GDB mailing list; it seemed like a good idea to solicit feedback from the rr developers first, to make sure the approach is considered appropriate on the rr side. Given that I don't know if any such proposal will be accepted for GDB or how much any accepted proposal may differ from above, I've submitted this as a draft PR for the time being.
Potential future directions
I'm also interested in feedback on the following ideas. I understand a discussion on these may be out of scope for this PR; let me know if you'd prefer separate issue(s).
GdbCommand.cc, allow (eventual?) removal of some of the GDB macros and hopefully bring a more consistent interface.info replay: Replaceelapsed-time,when,when-ticksandwhen-tidwith aninfo replaysubcommand. Strictly speaking, this doesn't need support from GDB, but it would be a good complement to GDB'sinfo recordsubcommand and GDB support would make it an interface consistent with other (hypothetical) GDB targets.