Bug 24073 - Breakpoint on the first insn of recorded history is not reported in replay
Summary: Breakpoint on the first insn of recorded history is not reported in replay
Status: UNCONFIRMED
Alias: None
Product: gdb
Classification: Unclassified
Component: record (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-07 15:59 UTC by Andrey Utkin
Modified: 2024-01-09 17:27 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
a patch (not style-compliant) (719 bytes, patch)
2019-01-07 15:59 UTC, Andrey Utkin
Details | Diff
reproducer script (134 bytes, application/x-shellscript)
2019-01-07 16:00 UTC, Andrey Utkin
Details
test debuggee (65 bytes, text/x-csrc)
2019-01-07 16:01 UTC, Andrey Utkin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrey Utkin 2019-01-07 15:59:48 UTC
Created attachment 11517 [details]
a patch (not style-compliant)

Currently, a breakpoint on the very same instruction which is the start of the recorded execution history, is never reported in replay. Neither when we reverse-execute towards it, nor when we "record goto start" to it, nor when we execute forwards after that.

A script to exercise this behaviour on a simple debuggee is attached.

A patch (previously submitted to gdb-patches as https://sourceware.org/ml/gdb-patches/2019-01/msg00074.html) is attached. The patch may be seen a bit too intrusive, I am more than happy to discuss and iterate on it.
Comment 1 Andrey Utkin 2019-01-07 16:00:11 UTC
Created attachment 11518 [details]
reproducer script
Comment 2 Andrey Utkin 2019-01-07 16:01:32 UTC
Created attachment 11519 [details]
test debuggee
Comment 3 Andrey Utkin 2019-01-07 16:06:45 UTC
The attached patch achieves reporting the breakpoint when reverse-executing towards it, but not when "record goto start" command is executed. (In UndoDB, with this GDB patch, we have a breakpoint notice on jump, too, but it's not considered a design goal at the moment).

Looking forward for any feedback from GDB maintainers (and particularly, reversible debugging maintainers).
Comment 4 Guinevere Larsen 2024-01-09 17:27:46 UTC
Hi Andrey!

Sorry about this going unnoticed for 5 years (My god this is too long a time). Reverse debugging wasn't getting much love at that time, but I've recently been appointed maintainer on this area, so I'd be able to review your patch. Are you still able and interested in contributing to this?

If you are, this patch needs a rebase, and needs to use ecs->ws.set_stopped instead of setting the signal and kind manually. It also needs a test in the style of the testsuite (written in TCL), there should be plenty of tests in the gdb/testsuite/gdb.record subdirectory to help (and of course, feel free to reach out in the gdb mailing list).

Most importantly, the commit message needs work. Commit logs should usually explain the issue, when applicable an example (in this case I don't really think it's necessary) and explain the solution in general terms. For instance, I expected this patch to always report that the end of story as a breakpoint hit and got really surprise that it doesn't. I think the commit message should explain why.