This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: Process record and replay checked in to main trunk
- From: "Marc Khouzam" <marc dot khouzam at ericsson dot com>
- To: "Hui Zhu" <teawater at gmail dot com>, <gdb-patches at sourceware dot org>
- Cc: "Pedro Alves" <pedro at codesourcery dot com>, "Michael Snyder" <msnyder at vmware dot com>, "Thiago Jung Bauermann" <bauerman at br dot ibm dot com>, "Eli Zaretskii" <eliz at gnu dot org>, "Mark Kettenis" <mark dot kettenis at xs4all dot nl>
- Date: Thu, 30 Apr 2009 10:42:31 -0400
- Subject: RE: Process record and replay checked in to main trunk
- References: <daef60380904300059g191dfe0bu7773ee01f35892bf@mail.gmail.com>
> Process record and replay make gdb can record inferior execute log and
> replay (include reverse debug).
> Now, it support I386-Linux single-thread single-inferior native debug.
>
> It was checked in today.
Congratulations!
I've checked-out the new HEAD and running PRecord in Eclipse
with no patches.
> Guys, please work on it if you interesting with some of them. And
> feel free tell me your ideas and comments. It will help precord a
> lot.
Here are some things I think would be nice:
1- The handling of queries in PRecord as we discussed in
http://sourceware.org/ml/gdb/2009-03/msg00194.html
2- speed (but you already mentioned you will work on this)
3- Some MI support
- 'record' and 'stoprecord' could have an MI equivalent
- trying to get the MI commands for Reverse debugging done
- *stopped MI event could/should have a special 'reason' field
when
it is triggered because Replay execution is finished.
Currently, there is no 'reason' field in this case.
Having the 'reason' field would allow a fronten to optionally
resume the execution at that point, instead of mysteriously
stopping when the Replay execution is finished.
I'm sure more suggestion will arise as people start using it.
Again, good work!
Marc