From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8659 invoked by alias); 20 Nov 2008 04:00:56 -0000 Received: (qmail 8502 invoked by uid 22791); 20 Nov 2008 04:00:55 -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.31) with ESMTP; Thu, 20 Nov 2008 04:00:10 +0000 Received: from d24relay01.br.ibm.com (unknown [9.8.31.16]) by igw3.br.ibm.com (Postfix) with ESMTP id 8070C390016 for ; Thu, 20 Nov 2008 01:57:46 -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 mAK4xhhk3694776 for ; Thu, 20 Nov 2008 01:59:43 -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 mAK406KD017622 for ; Thu, 20 Nov 2008 02:00:07 -0200 Received: from [9.8.3.184] ([9.8.3.184]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mAK406lE017618; Thu, 20 Nov 2008 02:00:06 -0200 Subject: Re: [RFA] Resubmit process record and replay, 5/10 From: Thiago Jung Bauermann To: Michael Snyder Cc: teawater , "gdb-patches@sourceware.org" In-Reply-To: <4924C246.6030104@vmware.com> References: <4924C246.6030104@vmware.com> Content-Type: text/plain; charset=utf-8 Date: Thu, 20 Nov 2008 08:33:00 -0000 Message-Id: <1227153607.28256.106.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 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-11/txt/msg00535.txt.bz2 El mié, 19-11-2008 a las 17:49 -0800, Michael Snyder escribió: > 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