From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-91138-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 8824 invoked by alias); 15 May 2012 16:42:26 -0000
Received: (qmail 8725 invoked by uid 22791); 15 May 2012 16:42:24 -0000
X-SWARE-Spam-Status: No, hits=-6.4 required=5.0	tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 May 2012 16:42:08 +0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q4FGfsZf012149	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);	Tue, 15 May 2012 12:41:54 -0400
Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1])	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q4FGfrcA014843	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);	Tue, 15 May 2012 12:41:54 -0400
From: Tom Tromey <tromey@redhat.com>
To: oza Pawandeep <oza.pawandeep@gmail.com>
Cc: Joel Brobecker <brobecker@adacore.com>, gdb@sourceware.org,        gdb-patches@sourceware.org
Subject: Re: [design change] record-replay linux ABI level
References: <CAK1A=4xtgYd8hQEwHxjLQiv4eqhCu0cSRDmmbFJvBDJwDxUM+Q__46748.0269181125$1336555010$gmane$org@mail.gmail.com>	<87sjf9qecr.fsf@fleche.redhat.com>	<CAK1A=4xbh0M=yfc2MQpZdDCJEPnL3_z8=TA0VSE7qVCoO0Dn-Q__42617.423789534$1336639800$gmane$org@mail.gmail.com>	<87aa1gqhnq.fsf@fleche.redhat.com>	<CAK1A=4wzBfbc1OpbP2BNMGVw0iiWMG81fy1+peq_r5rFkenyhA@mail.gmail.com>	<CAK1A=4zRULTC9Tue8Wu7vYpCiHE-sWBLHU7P9uw0d8MO0YRUpA@mail.gmail.com>	<CAK1A=4y7d8ot_G+O8oFm_ZVDT9q7QdFu87hMXT=+mHfVuJPnTw@mail.gmail.com>	<20120514145650.GF10253@adacore.com>	<CAK1A=4yervLeVDQ-r49n95ftrB27u8K+R1hfstz1oFwTNX=t7Q__24807.0006179207$1337059251$gmane$org@mail.gmail.com>
Date: Tue, 15 May 2012 16:42:00 -0000
In-Reply-To: <CAK1A=4yervLeVDQ-r49n95ftrB27u8K+R1hfstz1oFwTNX=t7Q__24807.0006179207$1337059251$gmane$org@mail.gmail.com>	(oza Pawandeep's message of "Tue, 15 May 2012 10:50:11 +0530")
Message-ID: <87havhtmzy.fsf@fleche.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.95 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2012-05/txt/msg00580.txt.bz2

>>>>> "Oza" == oza Pawandeep <oza.pawandeep@gmail.com> 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 generic
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?  Keep the current mapping idea, but extract
the mappings from syscalls/*.xml.  That way we help out two features
with a single data file.

Tom