From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12413 invoked by alias); 31 May 2009 17:47:52 -0000 Received: (qmail 12404 invoked by uid 22791); 31 May 2009 17:47:51 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_24 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 31 May 2009 17:47:46 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id n4VHlZqa003911; Sun, 31 May 2009 19:47:35 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id n4VHlY3b026655; Sun, 31 May 2009 19:47:34 +0200 (CEST) Date: Sun, 31 May 2009 17:47:00 -0000 Message-Id: <200905311747.n4VHlY3b026655@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: eliz@gnu.org CC: teawater@gmail.com, gdb@sourceware.org In-reply-to: <83iqji529q.fsf@gnu.org> (message from Eli Zaretskii on Sat, 30 May 2009 13:11:13 +0300) Subject: Re: System call support in process record and replay References: <83iqji529q.fsf@gnu.org> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-05/txt/msg00212.txt.bz2 > Date: Sat, 30 May 2009 13:11:13 +0300 > From: 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. 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.