This is the mail archive of the gdb@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: Re: ReBranch - a record-replay debugging tool


Hi,
ReBranch instruments all indirect branch instruction (such as jnz, jmp
*0x12345, call *%eax..., and syscall), records their branch targets.
For system calls, ReBranch also record their results (for write(),
ReBranch records its return value; for read(), ReBranch records its
return value as well as the data it retrieves). It also records the
result of 'rdtsc'.

All instrumentation is done dynamically at runtime -- no recompilation
or relinking is required.

 On , paawan oza <paawan1982@yahoo.com> wrote:
> Hi,
>
>
>
> Is it something like you do an instrumentation in object code....mostly at
> all
>
> control flows and system calls.
>
> and record some things.
>
> so indirectly you do not record every instruction, but you need to modify
> object
>
> code by binary instrumentation.
>
>
>
> but what I fail to understand is; what all do you record ?
>
>
>
>
>
> Regards,
>
> Oza.
>
>
>
>
>
>
>
> ----- Original Message ----
>
> From: Nan Wang pi3orama@gmail.com>
>
> To: Pedro Alves pedro@codesourcery.com>; gdb@sourceware.org
>
> Sent: Thu, June 9, 2011 10:09:09 PM
>
> Subject: Re: ReBranch - a record-replay debugging tool
>
>
>
> What I mean "control-flow only debugging" is:
>
>
>
> Sometimes user only use GDB's control-flow functions, such as 'c', 'b',
>
> 'n', 's' ... to watch how the program get to the bug. He or she doesn't
>
> care the variable name, the memory and some data-flow information.
>
>
>
> ReBranch demands "control-flow only debugging" because it only records
>
> every branch instruction. In current implementation (the modified
>
> version of gdbserver), the replayer still need to create a process and
>
> use ptrace to control it. When data-flow have error (caused by data-race
>
> in multi threading situation), the ptraced process will generate
>
> segfault for every instructions, which slows down the performance.
>
>
>
> ReBranch have a GUI replayer -- ReBranchK -- which is a simple
>
> control-flow-only debugging tool. ReBranchK doesn't really create the
>
> process and debug it. It 'executes' the program virtually by reads the
>
> log and shows corresponding source code. It implements 's', 'b' and 'c'
>
> command. However, when writing ReBranchK, I found that, without stack
>
> information, many useful control-flow command such as 'n' and 'bt' are
>
> hard to be implemented. Therefore, I hope someone help me to put this
>
> "control-flow only debugging" function into gdbserver.
>
> > Can you clarify what do you mean by "control-flow only debugging"?
>
> >
>
> > (Note: I haven't had the time yet to read your document on ReBranch,
>
> > so I don't really know how it works or why would you need gdbserver
>
> > for replay)
>
> >
>
>


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