public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: paawan oza <paawan1982@yahoo.com>
To: pi3orama <pi3orama@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: ReBranch - a record-replay debugging tool
Date: Fri, 10 Jun 2011 09:14:00 -0000	[thread overview]
Message-ID: <557317.1336.qm@web112513.mail.gq1.yahoo.com> (raw)
In-Reply-To: <4DF1D217.60103@gmail.com>

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)
>>

  reply	other threads:[~2011-06-10  9:14 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-09 16:39 Nan Wang
2011-06-09 19:20 ` paawan oza
     [not found]   ` <bcaec5215b03b867ea04a5500b35@google.com>
2011-06-10  1:55     ` pi3orama
2011-06-10  8:04       ` paawan oza
2011-06-10  8:15         ` pi3orama
2011-06-10  9:14           ` paawan oza [this message]
2011-06-10  9:36             ` pi3orama
2011-06-10  5:51 ` Yao Qi
2011-06-10  6:39   ` pi3orama
  -- strict thread matches above, loose matches on Subject: below --
2011-06-13  1:57 Robert Bu
2011-06-13  2:03 ` pi3orama
     [not found] <bcaec5395f2aa367da04a5462782@google.com>
2011-06-09 12:26 ` Pedro Alves
2011-06-09 12:54   ` pi3orama
2011-06-09 14:37   ` Joel Brobecker
2011-06-09 14:51     ` Pedro Alves
     [not found]       ` <BANLkTi=Mk0-PXb=7m0RZvEt7jegz17JXHw@mail.gmail.com>
2011-06-09 16:11         ` pi3orama
2011-06-09 16:20         ` Pedro Alves
     [not found] <1307602807.17016.ezmlm@sourceware.org>
2011-06-09  7:23 ` pi3orama
2011-06-09  9:27   ` Pedro Alves
2011-06-09 10:32     ` paawan oza
2011-06-09 13:05       ` pi3orama
     [not found]     ` <4DF0A729.4070106@gmail.com>
2011-06-09 11:23       ` Pedro Alves
2011-06-09 12:06         ` pi3orama

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=557317.1336.qm@web112513.mail.gq1.yahoo.com \
    --to=paawan1982@yahoo.com \
    --cc=gdb@sourceware.org \
    --cc=pi3orama@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).