Re: ReBranch - a record-replay debugging tool

[pi3orama <pi3orama@gmail.com>]

In multi-thread situation, nearly all data-flow information is lost
because of propagation. However, in single thread situation, signal
processing and system call results are all recorded and replayed, all
data-flow info can still be restored.

> ok got that point.
> so in conclusion, any data-flow info which is reponsible for crash may not be 
> caught by rebranch, or there is a way ?
>
> Regards,
> Oza.
>
>
>
>
> ----- Original Message ----
> From: pi3orama <pi3orama@gmail.com>
> To: paawan oza <paawan1982@yahoo.com>
> Cc: gdb@sourceware.org
> Sent: Fri, June 10, 2011 1:43:11 PM
> Subject: Re: ReBranch - a record-replay debugging tool
>
>
>> data-flow info is not recorded because assumption is: many of the 
>> non-deterministic bugs are control-flow level.
>>
>> so, if you do not have/or minial data-flow info, and if you only set 
>> link/branch 
>>
>> registers and instruction pointers, 
>>
>> then while replaying, do you think that program may not behave as in previous 
>> run because of loss of data flow info. 
>>
>> especially it may not take some of the branches which it previously took.
>>
>> because in you pdf example
>>
>> switch (X)   /* here branch is recorded but not X where X might have been 
>> changed before it, and when you reply it may take different branch */
>>
>> let me know if my thinking is ok in this sense.
>>
>> Regards,
>> Oza.
> ReBranch twists the branch if it goes to different target during replay.
> in my example, if switch statement goes to another case during replay,
> ReBranch will force the control flow back to the one in log. This is
> done by gdbserver patch.
>
>>
>> ----- Original Message ----
>> From: pi3orama <pi3orama@gmail.com>
>> To: paawan oza <paawan1982@yahoo.com>; Nan Wang <pi3orama@gmail.com>
>> Cc: gdb@sourceware.org
>> Sent: Fri, June 10, 2011 7:25:09 AM
>> Subject: 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)