From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32499 invoked by alias); 3 Dec 2008 01:34:43 -0000 Received: (qmail 32491 invoked by uid 22791); 3 Dec 2008 01:34:42 -0000 X-Spam-Check-By: sourceware.org Received: from igw3.br.ibm.com (HELO igw3.br.ibm.com) (32.104.18.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Dec 2008 01:33:52 +0000 Received: from d24relay01.br.ibm.com (unknown [9.8.31.16]) by igw3.br.ibm.com (Postfix) with ESMTP id 874FD39010C for ; Tue, 2 Dec 2008 23:30:45 -0200 (BRDT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB32XNTJ3395624 for ; Tue, 2 Dec 2008 23:33:23 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB31XmLV008929 for ; Tue, 2 Dec 2008 23:33:48 -0200 Received: from [9.18.201.180] ([9.18.201.180]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mB31Xmhe008926; Tue, 2 Dec 2008 23:33:48 -0200 Subject: Re: [RFA] Process record and replay, 5/10 From: Thiago Jung Bauermann To: teawater Cc: "gdb-patches@sourceware.org" In-Reply-To: References: <1226606210.4574.10.camel@localhost.localdomain> Content-Type: text/plain; charset=utf-8 Date: Wed, 03 Dec 2008 01:34:00 -0000 Message-Id: <1228268027.11550.112.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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/msg00044.txt.bz2 Hi teawater, Sorry for the big delay in my response. El vie, 14-11-2008 a las 16:36 +0800, teawater escribió: > On Fri, Nov 14, 2008 at 03:56, Thiago Jung Bauermann > wrote: > > 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. 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? 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). 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. > > 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". 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. > 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? Yes, it makes sense to me. -- []'s Thiago Jung Bauermann IBM Linux Technology Center