This is the mail archive of the
gdb@sourceware.org
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.
(P.S:
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.)
> Hi,
>
> 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.
>
> Robert
>
>> From: pi3orama <pi3orama@gmail.com>
>> To: paawan oza <paawan1982@yahoo.com>
>> 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 ?
>>>
>>> Regards,
>>> Oza.