System call support in process record and replay

System call support in process record and replay

[Eli Zaretskii]

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.

Re: System call support in process record and replay

[Doug Evans]

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.

Re: System call support in process record and replay

[Hui Zhu]

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

Re: System call support in process record and replay

[Mark Kettenis]

> Date: Sat, 30 May 2009 13:11:13 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> 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.

Eli, while your concerns are valid, I think that given the fact that
all Open Source OSes that I'm familliar with use the int 0x80 and/or
sysenter the current code is acceptable for now.  IMHO making the code
more complicated for "future flexibility" more often than not leads to
code that will never be used.  I think it is up to whoever adds
support for an OS that doesn't use int 0x80 to come up with a more
general solution.

Re: System call support in process record and replay

[Eli Zaretskii]

> Date: Sun, 31 May 2009 19:47:34 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: teawater@gmail.com, gdb@sourceware.org
> 
> I think it is up to whoever adds support for an OS that doesn't use
> int 0x80 to come up with a more general solution.

That's me ;-)  I intend to add support for DJGPP.  Thus my questions
(and the numbers of interrupts hinted on that, btw).

So please consider sharing your thoughts about this.

TIA

Re: System call support in process record and replay

[Michael Snyder]

Eli Zaretskii wrote:
>> Date: Sun, 31 May 2009 19:47:34 +0200 (CEST)
>> From: Mark Kettenis <mark.kettenis@xs4all.nl>
>> CC: teawater@gmail.com, gdb@sourceware.org
>>
>> I think it is up to whoever adds support for an OS that doesn't use
>> int 0x80 to come up with a more general solution.
> 
> That's me ;-)  I intend to add support for DJGPP.  Thus my questions
> (and the numbers of interrupts hinted on that, btw).
> 
> So please consider sharing your thoughts about this.

I think it's great that you're doing this.   ;-)

Re: System call support in process record and replay

[Andi Kleen]

Eli Zaretskii <eliz@gnu.org> writes:

> 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:

Note on modern x86 systems Linux doesn't even use INT 80h anymore for
syscalls, but typically SYSENTER (or sometimes SYSCALL)

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: System call support in process record and replay

[Hui Zhu]

On Mon, Jun 1, 2009 at 15:14, Andi Kleen <andi@firstfloor.org> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> 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:
>
> Note on modern x86 systems Linux doesn't even use INT 80h anymore for
> syscalls, but typically SYSENTER (or sometimes SYSCALL)
>

Linux 2.4 use it.