Re: System call support in process record and replay

[Hui Zhu <teawater@gmail.com>]

On Sun, May 31, 2009 at 05:12, Doug Evans <dje@google.com> wrote:
> On Sat, May 30, 2009 at 3:11 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> I have a question about general design of the system call support for
>> the record/replay target, for systems whose system calls are entered
>> through software interrupts.
>>
>> The following excerpt from i386-tdep.c shows the currently-only
>> implementation, for Linux system calls entered via INT 80h:
>>
>>    case 0xcd:
>>      {
>>        int ret;
>>        if (target_read_memory (ir.addr, &tmpu8, 1))
>>          {
>>            if (record_debug)
>>              printf_unfiltered (_("Process record: error reading memory "
>>                                   "at addr 0x%s len = 1.\n"),
>>                                 paddr_nz (ir.addr));
>>            return -1;
>>          }
>>        ir.addr++;
>>        if (tmpu8 != 0x80
>>            || gdbarch_tdep (gdbarch)->i386_intx80_record == NULL)
>>          {
>>            printf_unfiltered (_("Process record doesn't support "
>>                                 "instruction int 0x%02x.\n"),
>>                               tmpu8);
>>            ir.addr -= 2;
>>            goto no_support;
>>          }
>>        ret = gdbarch_tdep (gdbarch)->i386_intx80_record (ir.regcache);
>>        if (ret)
>>          return ret;
>>      }
>>      break;
>>
>> Now, suppose there is another x86 target whose system calls are
>> entered through 3 software interrupts: 0x10, 0x21, and 0x31.  Does
>> this mean that to support such a target, we will need to define 3
>> additional members of `struct gdbarch_tdep', one each for every one of
>> the above interrupt numbers, and then tweak the above code to call
>> each member whenever the corresponding interrupt number is seen in the
>> instruction stream?  And adding support for Windows syscalls means
>> that yet another member, for INT 2Eh, should be added?  That seems
>> rather inelegant and wasteful to me (since these members will go
>> unused on every x86 target that does not use those interrupts), but if
>> that's the design we want to follow, I'm okay with it.
>>
>
> fwiw, I concur.
> I'd like to see a lot of this stuff partitioned differently.
>

What about just keep one syscall interface, post opcode and addr to arch target.
Then the target can make sure if this syscall for it or not.

Hui