From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5115 invoked by alias); 10 Jun 2011 05:51:36 -0000 Received: (qmail 5103 invoked by uid 22791); 10 Jun 2011 05:51:35 -0000 X-SWARE-Spam-Status: No, hits=-0.6 required=5.0 tests=AWL,BAYES_00,MIME_CHARSET_FARAWAY,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 10 Jun 2011 05:51:20 +0000 Received: (qmail 14876 invoked from network); 10 Jun 2011 05:51:19 -0000 Received: from unknown (HELO ?192.168.0.102?) (yao@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Jun 2011 05:51:19 -0000 Message-ID: <4DF1B0CE.7070506@codesourcery.com> Date: Fri, 10 Jun 2011 05:51:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: ReBranch - a record-replay debugging tool References: <4DF0F72D.2020001@gmail.com> In-Reply-To: <4DF0F72D.2020001@gmail.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit 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/msg00062.txt.bz2 On 06/10/2011 12:39 AM, Nan Wang wrote: > 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. > "control-flow only" is a good idea, and I think that is the reason why your overhead, both on time and space, is so small. Good work! > 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 IIUC, you have an assumption there that "during record, program runs correctly, while during replace, program may run incorrectly", otherwise, you can't find the problem by comparing control-flow. The first half of assumption is OK, but the second half, which is more important, might not be. Some research works are focusing on how to expose/trigger non-deterministic program's faults. Your current approach in replaying looks fine, but if you want to find more bugs in replay, that might be the way to go. > segfault for every instructions, which slows down the performance. > I don't understand why "process will generate segfault for every instruction"? > 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. IIUC, you want to put your replayer function into gdbserver, in which, record log file, and checkpoints are input. User can connect to this special gdbsever to debug. Is that correct? Generally speaking, gdbserver supports multiple archs, so is your record log file format and checkpoints portable? -- Yao (ÆëÒ¢)