Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Yao Qi <yao@codesourcery.com>
To: gdb@sourceware.org
Subject: Re: ReBranch - a record-replay debugging tool
Date: Fri, 10 Jun 2011 05:51:00 -0000	[thread overview]
Message-ID: <4DF1B0CE.7070506@codesourcery.com> (raw)
In-Reply-To: <4DF0F72D.2020001@gmail.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=GB2312, Size: 2353 bytes --]

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 (ÆëÒ¢)


  parent reply	other threads:[~2011-06-10  5:51 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
2011-06-10  9:36             ` pi3orama
2011-06-10  5:51 ` Yao Qi [this message]
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=4DF1B0CE.7070506@codesourcery.com \
    --to=yao@codesourcery.com \
    --cc=gdb@sourceware.org \
    /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