From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31241 invoked by alias); 10 Jun 2011 09:36:12 -0000 Received: (qmail 31070 invoked by uid 22791); 10 Jun 2011 09:36:11 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-pv0-f169.google.com (HELO mail-pv0-f169.google.com) (74.125.83.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 10 Jun 2011 09:35:56 +0000 Received: by pvc12 with SMTP id 12so1386735pvc.0 for ; Fri, 10 Jun 2011 02:35:56 -0700 (PDT) Received: by 10.142.148.17 with SMTP id v17mr290014wfd.304.1307698556191; Fri, 10 Jun 2011 02:35:56 -0700 (PDT) Received: from [10.5.0.40] ([159.226.43.45]) by mx.google.com with ESMTPS id z7sm2681729wff.5.2011.06.10.02.35.53 (version=SSLv3 cipher=OTHER); Fri, 10 Jun 2011 02:35:54 -0700 (PDT) Message-ID: <4DF1E51F.1010501@gmail.com> Date: Fri, 10 Jun 2011 09:36:00 -0000 From: pi3orama User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110518 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: paawan oza CC: gdb@sourceware.org Subject: Re: ReBranch - a record-replay debugging tool References: <158712.44942.qm@web112515.mail.gq1.yahoo.com> <704470.84339.qm@web112516.mail.gq1.yahoo.com> <4DF1D217.60103@gmail.com> <557317.1336.qm@web112513.mail.gq1.yahoo.com> In-Reply-To: <557317.1336.qm@web112513.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-06/txt/msg00068.txt.bz2 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 > To: paawan oza > 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 >> To: paawan oza ; Nan Wang >> 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 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)