From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6166 invoked by alias); 30 May 2009 21:13:07 -0000 Received: (qmail 6156 invoked by uid 22791); 30 May 2009 21:13:06 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_24,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 30 May 2009 21:13:00 +0000 Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19]) by smtp-out.google.com with ESMTP id n4ULCujw011518 for ; Sat, 30 May 2009 22:12:57 +0100 Received: from yw-out-1718.google.com (ywq4.prod.google.com [10.192.17.4]) by zps19.corp.google.com with ESMTP id n4ULCsxf023936 for ; Sat, 30 May 2009 14:12:55 -0700 Received: by yw-out-1718.google.com with SMTP id 4so3236217ywq.88 for ; Sat, 30 May 2009 14:12:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.54.6 with SMTP id c6mr2079210aga.108.1243717974491; Sat, 30 May 2009 14:12:54 -0700 (PDT) In-Reply-To: <83iqji529q.fsf@gnu.org> References: <83iqji529q.fsf@gnu.org> Date: Sat, 30 May 2009 21:13:00 -0000 Message-ID: Subject: Re: System call support in process record and replay From: Doug Evans To: Eli Zaretskii Cc: Hui Zhu , gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true 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/msg00197.txt.bz2 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 re= ading memory " > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "at a= ddr 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 suppo= rt " > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "instruct= ion 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.reg= cache); > =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.