From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28021 invoked by alias); 14 Nov 2008 08:37:42 -0000 Received: (qmail 27944 invoked by uid 22791); 14 Nov 2008 08:37:41 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.191) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 14 Nov 2008 08:36:50 +0000 Received: by ti-out-0910.google.com with SMTP id d10so1031933tib.12 for ; Fri, 14 Nov 2008 00:36:46 -0800 (PST) Received: by 10.110.103.5 with SMTP id a5mr793900tic.26.1226651806514; Fri, 14 Nov 2008 00:36:46 -0800 (PST) Received: by 10.110.103.3 with HTTP; Fri, 14 Nov 2008 00:36:46 -0800 (PST) Message-ID: Date: Fri, 14 Nov 2008 13:53:00 -0000 From: teawater To: "Thiago Jung Bauermann" Subject: Re: [RFA] Process record and replay, 5/10 Cc: "gdb-patches@sourceware.org" In-Reply-To: <1226606210.4574.10.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1226606210.4574.10.camel@localhost.localdomain> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-11/txt/msg00324.txt.bz2 Thanks Thiago. On Fri, Nov 14, 2008 at 03:56, Thiago Jung Bauermann wrote: > El jue, 06-11-2008 a las 15:48 +0800, teawater escribi=F3: >> +/* Record the values of the registers and memory that will be changed in >> + current system call. >> + Return -1 if something wrong. */ >> + >> +int >> +record_linux_system_call (int num, linux_record_tdep_t * tdep) >> +{ >> + uint32_t tmpu32; >> + >> + switch (num) >> + { > >> + /* sys_read */ >> + case 3: >> + { >> + uint32_t addr, count; >> + regcache_raw_read (record_regcache, tdep->arg2, (gdb_byte *) & add= r); >> + regcache_raw_read (record_regcache, tdep->arg3, (gdb_byte *) & cou= nt); >> + if (record_arch_list_add_mem (addr, count)) >> + { >> + return (-1); >> + } >> + } >> + break; > >> + case 84: >> + regcache_raw_read (record_regcache, tdep->arg2, (gdb_byte *) & tm= pu32); >> + if (record_arch_list_add_mem (tmpu32, tdep->size__old_kernel_stat= )) >> + { >> + return (-1); >> + } >> + break; > > Syscalls have different numbers across different architectures in Linux, > so this file should be named i386-linux-record.c. This number is same with i386 number. It's friendly to other arch. Let me do a introduce of it. When a record get a system call. It will get the the system number with itself and convert it to the number that you found in linux-record.c. I think it can use a table or something like it to make covert speed up. There is not some limit of this number. So I make it same with I386. > > Do you know if what you need to record for a syscall in one architecture > is the same as what you need to record in the others? If so, it wouldn't > be hard to make this file general for Linux in all architectures, and > just get the syscall number mapping from the XML in the catch syscall > feature (here are we talking about it again... :-) ). Otherwise, you'll > have to rename the file, and also you can't directly call > record_linux_system_call directly from i386-linux-tdep.c like you do > now. You'd have to add a gdbarch method and reach this code through > that. I think most of system call in each arch are same. Except the size of variables is not same. So I let arch set the size to argv "tdep" of record_linux_system_call. And if some system call of a arch is not same with others. It can deal with it in code of itself. For example, If i386 have a special system call that not same with other arch. It can deal with it in function "i386_linux_intx80_sysenter_record". Put it to xml file it's been talk in "http://sourceware.org/ml/gdb-patches/2008-11/msg00171.html". What about do it later? Hui