This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ReBranch - a record-replay debugging tool


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 (齐尧)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]