From: Marc Khouzam <marc.khouzam@ericsson.com>
To: "'Michael Snyder'" <msnyder@vmware.com>,
"'gdb@sourceware.org'" <gdb@sourceware.org>
Subject: RE: [FYI] tutorial for process record and reverse debugging
Date: Mon, 19 Oct 2009 12:57:00 -0000 [thread overview]
Message-ID: <F7CE05678329534C957159168FA70DEC5157A95F5C@EUSAACMS0703.eamcs.ericsson.se> (raw)
In-Reply-To: <4ADA4BD8.6080800@vmware.com>
> -----Original Message-----
> From: gdb-owner@sourceware.org
> [mailto:gdb-owner@sourceware.org] On Behalf Of Michael Snyder
> Sent: Saturday, October 17, 2009 6:57 PM
> To: gdb@sourceware.org
> Subject: [FYI] tutorial for process record and reverse debugging
>
> FYI, there is now a tutorial for process record/replay and reverse
> debugging on the gdb wiki:
>
> http://sourceware.org/gdb/wiki/ProcessRecord/Tutorial
Very clearly written. It should be very useful.
I even learned that the following was a wanted behavior:
"We can go directly to the point at which the recording currently ends, by disabling
all our breakpoints and then telling gdb to continue. Process record will replay
until it reaches the current end of the recording, and then stop."
To be honest, I never cared much for this behavior because from an Eclipse
user-experience, it is not very clear why the execution/replay suddenly stops in
this case.
But from reading the tutorial I see that it may be of interest in some situations.
What bothers me though is that one must disable all breakpoints and then re-enable
them. This can be a bit of an annoyance, especially if some bps were already disabled.
I got to wonder if this doesn't call for a new command; something like
"record live", which would take us to the end of the recording while not needing the
user to deal with existing breakpoints.
What do you think?
Marc
next prev parent reply other threads:[~2009-10-19 12:36 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-17 23:48 Michael Snyder
2009-10-19 12:36 ` Hui Zhu
2009-10-19 12:57 ` Marc Khouzam [this message]
2009-10-19 13:06 ` Hui Zhu
2009-10-19 13:20 ` Marc Khouzam
2009-10-19 16:35 ` Hui Zhu
2009-10-20 0:59 ` Michael Snyder
2009-10-19 18:24 ` Michael Snyder
2009-10-20 6:44 ` Marc Khouzam
2009-10-20 21:01 ` Michael Snyder
2009-10-21 5:16 ` Greg Law
2009-10-21 15:40 ` Marc Khouzam
2009-10-24 19:29 ` Greg Law
2009-10-25 2:01 ` Michael Snyder
2009-10-26 3:05 ` Marc Khouzam
2009-10-26 9:59 ` Jakob Engblom
2009-10-22 6:31 ` Michael Snyder
2009-10-21 15:06 ` Marc Khouzam
2009-10-26 7:54 ` Hui Zhu
2009-10-26 8:06 ` Jakob Engblom
2009-10-26 7:58 ` Jakob Engblom
2009-10-26 19:10 ` Michael Snyder
2009-10-27 18:32 ` Jakob Engblom
2009-10-19 18:23 ` Michael Snyder
2009-10-26 3:12 ` Hui Zhu
2009-10-26 8:02 ` Jakob Engblom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F7CE05678329534C957159168FA70DEC5157A95F5C@EUSAACMS0703.eamcs.ericsson.se \
--to=marc.khouzam@ericsson.com \
--cc=gdb@sourceware.org \
--cc=msnyder@vmware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox