RE: System call support in reversible debugging

["Jakob Engblom" <jakob at virtutech dot com>]

> >> Hi Michael and Hui,
> >>
> >> I am sorry for my late response.
> >>
> >> Thanks for your explanation. So we can't treat the system calls as a
> >> black box and have to understand the detailed implementation of each
> >> system call. I think we need to understand every lines of the code in
> >> the system calls carefully enough, and care about the difference of
> >> the Linux kernel since the code of system calls might change
> >> frequently. Do we have any good ways to do it?
> >
> > To really do this right, you should use a full-system simulator that lets
you
> > debug OS and user code at the same time, as it is attacking the system at
the
> > hardware/software interface level.
> 
> It all depends what you want to do.
> 
> If you want to debug kernel code, then absolutely you need a full system
> approach, such as Simics or VMware offers.  Similarly if you want to
> debug the whole host.  But if you're debugging just a process (i.e. the
> classic use-case of gdb), you may not want to wind back the state of the
> entire (virtual) machine.  In which case, something like UndoDB or prec
> is more appropriate.
> 
> I don't claim either approach is superior.  It's a bit like native
> debugging versus remote debugging.  Which one makes most sense all
> depends on what it is you're trying to debug.

Couldn't agree more.  The full-system approach is a bit more gnarly, but it
gives you more insight.  It depends on the problem.

/jakob