This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: System call support in process record and replay
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: eliz at gnu dot org
- Cc: teawater at gmail dot com, gdb at sourceware dot org
- Date: Sun, 31 May 2009 19:47:34 +0200 (CEST)
- Subject: Re: System call support in process record and replay
- References: <83iqji529q.fsf@gnu.org>
> 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.