From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20856 invoked by alias); 31 May 2009 05:58:40 -0000 Received: (qmail 20847 invoked by uid 22791); 31 May 2009 05:58:40 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_24,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-pz0-f175.google.com (HELO mail-pz0-f175.google.com) (209.85.222.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 31 May 2009 05:58:35 +0000 Received: by pzk5 with SMTP id 5so6987362pzk.12 for ; Sat, 30 May 2009 22:58:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.110.16.9 with SMTP id 9mr114084tip.2.1243749513351; Sat, 30 May 2009 22:58:33 -0700 (PDT) In-Reply-To: References: <83iqji529q.fsf@gnu.org> Date: Sun, 31 May 2009 05:58:00 -0000 Message-ID: Subject: Re: System call support in process record and replay From: Hui Zhu To: Doug Evans Cc: Eli Zaretskii , gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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/msg00210.txt.bz2 On Sun, May 31, 2009 at 05:12, Doug Evans wrote: > On Sat, May 30, 2009 at 3:11 AM, Eli Zaretskii 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: >> >> =A0 =A0case 0xcd: >> =A0 =A0 =A0{ >> =A0 =A0 =A0 =A0int ret; >> =A0 =A0 =A0 =A0if (target_read_memory (ir.addr, &tmpu8, 1)) >> =A0 =A0 =A0 =A0 =A0{ >> =A0 =A0 =A0 =A0 =A0 =A0if (record_debug) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0printf_unfiltered (_("Process record: error r= eading memory " >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "at = addr 0x%s len =3D 1.\n"), >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 paddr_nz= (ir.addr)); >> =A0 =A0 =A0 =A0 =A0 =A0return -1; >> =A0 =A0 =A0 =A0 =A0} >> =A0 =A0 =A0 =A0ir.addr++; >> =A0 =A0 =A0 =A0if (tmpu8 !=3D 0x80 >> =A0 =A0 =A0 =A0 =A0 =A0|| gdbarch_tdep (gdbarch)->i386_intx80_record =3D= =3D NULL) >> =A0 =A0 =A0 =A0 =A0{ >> =A0 =A0 =A0 =A0 =A0 =A0printf_unfiltered (_("Process record doesn't supp= ort " >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "instruc= tion int 0x%02x.\n"), >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tmpu8); >> =A0 =A0 =A0 =A0 =A0 =A0ir.addr -=3D 2; >> =A0 =A0 =A0 =A0 =A0 =A0goto no_support; >> =A0 =A0 =A0 =A0 =A0} >> =A0 =A0 =A0 =A0ret =3D gdbarch_tdep (gdbarch)->i386_intx80_record (ir.re= gcache); >> =A0 =A0 =A0 =A0if (ret) >> =A0 =A0 =A0 =A0 =A0return ret; >> =A0 =A0 =A0} >> =A0 =A0 =A0break; >> >> Now, suppose there is another x86 target whose system calls are >> entered through 3 software interrupts: 0x10, 0x21, and 0x31. =A0Does >> 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? =A0And adding support for Windows syscalls means >> that yet another member, for INT 2Eh, should be added? =A0That 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 ta= rget. Then the target can make sure if this syscall for it or not. Hui