Re: Process record and replay checked in to main trunk

[Hui Zhu <teawater@gmail.com>]

Hi Eli,

On Fri, May 1, 2009 at 21:27, Eli Zaretskii <eliz@gnu.org> wrote:
> It would be nice if i386-tdep.c had some comments about what it takes
> for another x86 target to add support for process recording and
> replay.  Apologies if it's already described somewhere and I missed
> it.
>
> It looks like all is needed is to define suitable functions for
> tdep->i386_intx80_record and tdep->i386_sysenter_record, is that
> right?  (If so, why so Linux-centric names?)

The intx80 and sysenter function pointers is the interface for
i386-os-tdep code to set intx86 insn and sysenter special record
functions.
Because some os (linux) have special function in intx80 and sysenter
(system call).

So, in other arch, maybe there will have other interface.  For
example, arm will have a swi interface, mips will have a syscall
interface.

>
> Also, some architectural overview of how the record/replay target
> works would be nice, either in the comments or in gdbint.texinfo.  For
> example, just looking at i386_linux_intx80_sysenter_record, I cannot
> understand how it succeed to record both the arguments to the syscall
> and the return value.  The syscall itself does not happen inside
> record_linux_system_call, that just records the syscall parameters and
> data buffers, right?  And recording happens _before_ the instruction
> being recorded executes, right?  So how come
> i386_linux_intx80_sysenter_record can use EAX as the syscall number
> and immediately after the call to record_linux_system_call treat the
> value of EAX as the value returned by the syscall?  What am I missing
> here?

This is because all record work will be done before insn execute.
Before insn execute, p record parse this insn.  Find out which
register and memory will be changed in this insn.  Record the old
value of the reg and mem.
So, syscall doesn't really need execute in function
i386_linux_intx80_sysenter_record.

>
> It probably doesn't help that I don't know enough about how the target
> stack works, but that isn't described, either, at least not in
> target.[ch], right?  The only thing I found is some very high-level
> description at the beginning of target.h.
>
I don't know which doc have the description for.  Maybe read code
target.c:update_current_target will help to make clear stack works.


All of them are very good questions.  Please tell me if you still have
problems with them.


Thanks,
Hui