From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29342 invoked by alias); 24 Nov 2008 03:35:22 -0000 Received: (qmail 29258 invoked by uid 22791); 24 Nov 2008 03:35:21 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.187) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 24 Nov 2008 03:34:31 +0000 Received: by ti-out-0910.google.com with SMTP id d10so1131841tib.12 for ; Sun, 23 Nov 2008 19:34:20 -0800 (PST) Received: by 10.110.41.17 with SMTP id o17mr4259858tio.10.1227497660346; Sun, 23 Nov 2008 19:34:20 -0800 (PST) Received: by 10.110.103.3 with HTTP; Sun, 23 Nov 2008 19:34:20 -0800 (PST) Message-ID: Date: Mon, 24 Nov 2008 16:50:00 -0000 From: teawater To: "Thiago Jung Bauermann" Subject: Re: [RFA] Resubmit process record and replay, 5/10 Cc: "Michael Snyder" , "gdb-patches@sourceware.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4924C246.6030104@vmware.com> <1227153607.28256.106.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/msg00634.txt.bz2 Hi Thiago, Sorry to disturb you. Could you help me on http://sourceware.org/ml/gdb-patches/2008-11/msg00536.= html Thanks, Hui On Thu, Nov 20, 2008 at 16:45, teawater wrote: > According to your mail. I think maybe you didn't get my answer. And I > am sorry that send "[RFA] Resubmit" without get you answer. > > http://sourceware.org/ml/gdb-patches/2008-11/msg00310.html > Following is the content of the answer: > 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 *) & ad= dr); >>> + regcache_raw_read (record_regcache, tdep->arg3, (gdb_byte *) & co= unt); >>> + if (record_arch_list_add_mem (addr, count)) >>> + { >>> + return (-1); >>> + } >>> + } >>> + break; >> >>> + case 84: >>> + regcache_raw_read (record_regcache, tdep->arg2, (gdb_byte *) & t= mpu32); >>> + if (record_arch_list_add_mem (tmpu32, tdep->size__old_kernel_sta= t)) >>> + { >>> + 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 > > > On Thu, Nov 20, 2008 at 12:00, Thiago Jung Bauermann > wrote: >> El mi=E9, 19-11-2008 a las 17:49 -0800, Michael Snyder escribi=F3: >>> Thiago, you had a question about whether the syscall id numbers >>> were invariant across architectures, and I think Hui answered that >>> he was using the i386 numbering as representative, and would use >>> a target-specific header file or something to translate them. >>> >>> Or something to that effect. >>> >>> Did that answer your concern? >> >> I had two different but related concerns, regarding this 5th patch: >> >> 1. linux-record.c is really i386 specific, so it should be called >> i386-linux-record.c. >> >> 2. If the information that needs to be recorded for each syscall (not >> the syscall number) is the same accross architectures, the code in >> linux-record.c could be made arch-independent and then we wouldn't need >> to have this big chunk of code duplicated for each arch supporting >> record functionality. >> >> I'm fine with leaving 2 to be investigated/addressed when record adds >> support for its 2nd arch. It also may prove impractical, since there may >> be slight differences in syscalls for each arch. >> -- >> []'s >> Thiago Jung Bauermann >> IBM Linux Technology Center >> >> >