This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [discuss] Support for reverse-execution
- From: Daniel Jacobowitz <drow at false dot org>
- To: Paul Schlie <schlie at comcast dot net>
- Cc: Dan Shearer <dan at shearer dot org>, gdb at sources dot redhat dot com
- Date: Fri, 20 May 2005 20:58:45 -0400
- Subject: Re: [discuss] Support for reverse-execution
- References: <20050520220807.GA11445@nevyn.them.org> <BEB3E025.A3AD%schlie@comcast.net>
On Fri, May 20, 2005 at 06:42:45PM -0400, Paul Schlie wrote:
> - Which is fully your right to claim/believe; however noting the absence
> of non-proprietary simulators with these capabilities (it's a little
> unclear how one can presume that interfaces are likely most ideally
> necessary or appropriate; and simply note that register and memory state
> by definition is program state, which GDB already has direct access to).
That is incorrect. There can be considerably more state. For
instance, I understand from Dan's explanation that Simics will reply
external interrupt sources - at the same clock cycles where they would
otherwise have occurred.
> As an aside and personal opinion, I happen believe it's not likely good
> form to define "opaque" interfaces to non-FSF tools without at least
> simultaneously implementing a non-opaque/proprietary solution (which is
> I guess the same philosophical problem that I have with the sourcing of
> any information, including potentially proprietary extended register/ISA
> definitions through an "opaque" interface/wall).
It's no more opaque than the continue command is opaque.
--
Daniel Jacobowitz
CodeSourcery, LLC