This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC/RFA] gdbreplay V2.0


It can work with reverse command of "msnyder-reverse-20080609-branch"?

On Wed, Jul 2, 2008 at 12:49, Michael Snyder <msnyder@specifix.com> wrote:
> Here's a new contribution -- I call it gdb-freeplay, an
> improved and less restrictive version of gdbreplay.  Its
> something I've been playing around with for some time now.
>
> This is a remote protocol logger/replayer, that works in
> principal just like gdbreplay -- it even uses the same
> logfiles, with no changes or enhancements.
>
> However, where gdbreplay constrains you in the replay session
> to giving *exactly* the same commands, in *exactly* the same
> sequence, as were used in the recorded session, gdb-freeplay
> frees you of that constraint -- you can change the order of
> the commands, or skip them entirely, even skip ahead past an
> arbitrary number of execution events to get to the "interesting"
> ones.
>
> You use step and next just like you did in the recorded
> session, but now you can set a breakpoint and continue on
> ahead to a later part of the session, even if you did not
> do so in the original session.  You can even next over a
> function call that you originally stepped into -- so long
> as you also stepped out of it.  Or you can skip out with
> "finish", even if you continued to debug the function
> interminably in the original session.
>
> You can print any variable(s) or registers that you
> examined before, in any order, even combine them into
> expressions that were not used in the recorded session
> (so long as all the values of the expression were evaluated).
> In many ways, it's a lot like tracepoint debugging.
>
> I picture it being useful for gdb testing -- we might
> even create hand-crafted "sessions" and use it to play
> them back to explicitly test parts of the remote protocol.
>
> I can also picture a user sending you a binary and a
> recorded log in which a bug happened -- you could debug
> it even with a cross-debugger, lacking the appopriate
> hardware (or simulator or what have you) -- and even if
> the recorded log was 50 megabytes long, you could skip
> ahead to the interesting bits.
>
> But frankly, I just wrote it because it was fascinating to do...
>
> Michael
>
> PS I've already written back-ends for x86, MIPS64, and x86-64.
> Most other target architectures should be fairly easy to add,
> and it will work with anything that uses the remote protocol.
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]