This is the mail archive of the
mailing list for the GDB project.
Re: ReBranch - a record-replay debugging tool
- From: pi3orama <pi3orama at gmail dot com>
- To: Robert Bu <robert dot bu at gmail dot com>
- Cc: gdb at sourceware dot org
- Date: Mon, 13 Jun 2011 10:01:01 +0800
- Subject: Re: ReBranch - a record-replay debugging tool
- References: <BANLkTi=ziszkXzPZE-P2TEewmJrfN3Op0Q@mail.gmail.com>
Yes, you are right.
On the perspective of user processes, all IO interactions are come from
system calls, so for single thread processes, most of the time recording
system calls is enough for data-flow. The only exception I have seen is
vmsplice(): it temporary makes shared memory between 2 processes.)
> For data flow, recording syscall is not enough. There may be IO interaction.
> I think your current implementation looks like a PC tracing, replaying tool.
>> From: pi3orama <email@example.com>
>> To: paawan oza <firstname.lastname@example.org>
>> Date: Fri, 10 Jun 2011 17:34:23 +0800
>> Subject: Re: ReBranch - a record-replay debugging tool
>> 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 ?