From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5450 invoked by alias); 3 Dec 2008 02:57:21 -0000 Received: (qmail 5441 invoked by uid 22791); 3 Dec 2008 02:57:20 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.186) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Dec 2008 02:56:45 +0000 Received: by ti-out-0910.google.com with SMTP id d10so2174123tib.12 for ; Tue, 02 Dec 2008 18:56:43 -0800 (PST) Received: by 10.110.53.14 with SMTP id b14mr6964842tia.30.1228273002899; Tue, 02 Dec 2008 18:56:42 -0800 (PST) Received: by 10.110.43.10 with HTTP; Tue, 2 Dec 2008 18:56:42 -0800 (PST) Message-ID: Date: Wed, 03 Dec 2008 02:57: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: <1228268027.11550.112.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> <1228268027.11550.112.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-12/txt/msg00045.txt.bz2 Thanks Thiago, On Wed, Dec 3, 2008 at 09:33, Thiago Jung Bauermann w= rote: > Hi teawater, > > Sorry for the big delay in my response. Never mind. :) > > El vie, 14-11-2008 a las 16:36 +0800, teawater escribi=F3: >> On Fri, Nov 14, 2008 at 03:56, Thiago Jung Bauermann >> wrote: >> > Syscalls have different numbers across different architectures in Linu= x, >> > 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. > > So are you saying that record_linux_system_call takes a syscall number > which is internal to GDB and doesn't necessarily correspond to the > syscall numbers used in the target? > Yes. > Right now there's only the i386 implementation of record, so the > internal implementation is equivalent to it (and indeed, > i386_linux_intx80_sysenter_record takes the syscall number from the > register and passes it to record_linux_system_call). Yes, that is what it does. > > If that is the case, then I'm ok. But a comment in > record_linux_system_call explaining this intended use would help someone > wanting to add record support to a new architecture. OK. I will. > >> > Do you know if what you need to record for a syscall in one architectu= re >> > 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". > > I like this idea. I don't have any authority or experience to make > recommendations about this, but I'd guess that like you say, most > syscalls across architectures in Linux would be similar and mostly > differ by sizes of types and structures. If exceptions to this rule can > be dealt with separately, than most of the laborious syscall-recording > work can be reused in record_linux_system_call. Sounds great, thanks for > the explanation. > > If you could mention this intention of reusing this function for other > architectures, that would tip someone wanting to port record to another > architecture, IMHO. Yes, that is what I try to do. Thanks for your explain. That is much better than me. I will add them to comments if you don't mind. :) Hui