From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28584 invoked by alias); 1 Sep 2009 06:37:32 -0000 Received: (qmail 28448 invoked by uid 22791); 1 Sep 2009 06:37:30 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from vtab.com (HELO oden.vtab.com) (62.20.90.195) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 01 Sep 2009 06:37:21 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id 5AB8626EF49; Tue, 1 Sep 2009 08:37:19 +0200 (CEST) Received: from polhem (95.209.37.191.bredband.tre.se [95.209.37.191]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oden.vtab.com (Postfix) with ESMTP id 6FB4626EF3A; Tue, 1 Sep 2009 08:37:18 +0200 (CEST) From: "Jakob Engblom" To: "'Greg Law'" Cc: "'Michael Snyder'" , References: <002001ca1f0e$4c9b74a0$e5d25de0$@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> In-Reply-To: <4A9BF84F.3070404@undo-software.com> Subject: RE: Simics & reverse execution Date: Tue, 01 Sep 2009 06:37:00 -0000 Message-ID: <025201ca2ace$a9256430$fb702c90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00000.txt.bz2 > 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