This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: Simics & reverse execution
- From: "Jakob Engblom" <jakob at virtutech dot com>
- To: "'Greg Law'" <glaw at undo-software dot com>
- Cc: "'Michael Snyder'" <msnyder at vmware dot com>, <gdb at sourceware dot org>
- Date: Tue, 1 Sep 2009 08:37:12 +0200
- Subject: RE: Simics & reverse execution
- References: <002001ca1f0e$4c9b74a0$e5d25de0$@com> <daef60380908170058i455ee534l527e58238a0839b9@mail.gmail.com> <002101ca1f2e$746e1ad0$5d4a5070$@com> <200908171251.07179.pedro@codesourcery.com> <4A899E2E.6080203@vmware.com> <00b801ca1f74$e5610a90$b0231fb0$@com> <4A89B7E4.9010804@vmware.com> <027701ca209f$64c71ce0$2e5556a0$@com> <4A95E319.6020300@vmware.com> <4A97B9C9.8070501@greglaw.net> <010b01ca2a3c$7766ca70$66345f50$@com> <4A9BF84F.3070404@undo-software.com>
> If the 64 bits of the integer were to be considered 'opaque' and no more
> than a unique handle onto a point in history, that would be fine. But
> such a restriction is unfortunate, because you wouldn't be able to e.g.
> binary chop history.
But on which side of the debugger connection would you do this?
This can work eminently with opaque IDs: just have your scripted backend setup
the binary search or whatever, telling gdb that new bookmarks have appeared as
it runs.
Actually, I think an important feature here would be to push bookmarks from the
backend to the gdb. So that the backend can provide useful insights to gdb.
This also lets the backend in some ways hook debug events that gdb has no idea
about, such as interrupts, hardware accesses, hypervisor activity that switches
around operating systems, and other things.
/jakob