From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30198 invoked by alias); 16 May 2012 10:48:20 -0000 Received: (qmail 30179 invoked by uid 22791); 16 May 2012 10:48:19 -0000 X-SWARE-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-we0-f169.google.com (HELO mail-we0-f169.google.com) (74.125.82.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 May 2012 10:48:06 +0000 Received: by wefh52 with SMTP id h52so447321wef.0 for ; Wed, 16 May 2012 03:48:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.74.68 with SMTP id r4mr6766426wiv.13.1337165285238; Wed, 16 May 2012 03:48:05 -0700 (PDT) Received: by 10.180.164.142 with HTTP; Wed, 16 May 2012 03:48:05 -0700 (PDT) In-Reply-To: <87havhtmzy.fsf@fleche.redhat.com> References: <87sjf9qecr.fsf@fleche.redhat.com> <87aa1gqhnq.fsf@fleche.redhat.com> <20120514145650.GF10253@adacore.com> <87havhtmzy.fsf@fleche.redhat.com> Date: Wed, 16 May 2012 10:48:00 -0000 Message-ID: Subject: Re: [design change] record-replay linux ABI level From: oza Pawandeep To: Tom Tromey Cc: Joel Brobecker , gdb@sourceware.org, gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00073.txt.bz2 Tom, a) yes; The record_linux_system_call is a problem because the conflicting number would conflict in {switch} {case} construct of the functions. b) I am not much familiar with xml generated C files, and where to change in gdb, but with that, will the record_linux_system_call be able to incorporate all conflicting syscall numbers in that case ? c) there is another way, which is align to current design. (it is not very very clean but manageable) define as follows enum gdb_syscall { /* i386 related syscalls */ /* ARM related syscalls */ /* MIPS related syscalls */ so on.. } if syscalls share the same number then it is one-to-one mapping. if at the same number, syscalls are different then add them under ARM number which would start just after i386. if there are common syscalls but different number then there would be shift by a number. then it has to be adjusted in function static enum gdb_arm_syscall arm_canonicalize_syscall (int syscall) { enum { arm_sys_prlimit64 =3D 369 }; if (syscall <=3D arm_sys_prlimit64) return syscall; else return -1; } Regards, Oza. On Tue, May 15, 2012 at 10:11 PM, Tom Tromey wrote: >>>>>> "Oza" =3D=3D oza Pawandeep writes: > > Oza> I would have liked to think the same; but the way linux-record.h > Oza> addresses all the architecture, the enum sycall, is defiend > Oza> generically. > > Oza> what I think is define it in arch files, as syscalls are partially > Oza> dependent on arch, though they follow posix standard. > > Oza> so each arch file would have their own map, compare to current gener= ic > Oza> map in linux-record.h > > If it really makes things better, it is fine by me. > > What do you propose to do with record_linux_system_call? > > > How about another approach? =A0Keep the current mapping idea, but extract > the mappings from syscalls/*.xml. =A0That way we help out two features > with a single data file. > > Tom