From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27104 invoked by alias); 29 Apr 2015 10:01:39 -0000 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 Received: (qmail 27093 invoked by uid 89); 29 Apr 2015 10:01:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 29 Apr 2015 10:01:36 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3TA1VfD032749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 29 Apr 2015 06:01:31 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3TA1SSe032655; Wed, 29 Apr 2015 06:01:29 -0400 Message-ID: <5540ABF8.4000404@redhat.com> Date: Wed, 29 Apr 2015 10:44:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Sergio Durigan Junior CC: Gabriel Krisman Bertazi , gdb-patches@sourceware.org, dje@google.com Subject: Re: [PATCH v3 00/17] Catch syscall group References: <1430011521-24340-1-git-send-email-gabriel@krisman.be> <553F6BC0.9000905@redhat.com> <87r3r42e0v.fsf@redhat.com> In-Reply-To: <87r3r42e0v.fsf@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-04/txt/msg01062.txt.bz2 On 04/28/2015 09:28 PM, Sergio Durigan Junior wrote: > On Tuesday, April 28 2015, Pedro Alves wrote: > >> I was wondering if we couldn't share most of the grouping >> per-architecture, e.g., by having each arch syscall file xi:include a >> base Linux default groups file, that listed the grouping without >> the syscall number. E.g., create a linux-defaults.xml like: >> > Thanks for the review, Pedro. I think this is a nice idea, but I would > like to propose that we accept the patches as-is, without this > improvement, and then work on it later. First, it's been a long time > since we're discussing this feature, and I don't want Krisman to not > feel encouraged to continue contributing :-). I think there's a difference from the feature itself, which was discussed and I'm generally fine with, and the whole set of patches that are new in this new revision of the series. Those are revealing a problem that I think should be addressed. > Also, I think the syscall > XML generation really needs a revamp, independently of how/if we use > groups or not. There should be possible, for example, to easily update > the XML's with the latest Linux kernel source. This task is on my > plate, though it's a low priority. So, for now, I think Krisman's work > is good enough. Updating the XML's from the Linux source is a different thing. That would only regenerate the set of syscalls and its numbers. The grouping is not something that can be extracted out of the kernel. Note Gabriel is already using scripts to generate the xmls (hence my questions in the previous email): > The previous version only implemented syscalls for amd64. I used a > script to generate the xmls, and based the group field information on > strace, so please share your thoughts if you disagree with any group. ... and this shows the issue that I'm seeing: we have seemingly the same grouping done _14_ times. That's not a sign of something that is maintainable. Maybe the linux-defaults.xml idea was overcomplicated. The main take away is that the syscall grouping should be the same everywhere, which suggests that the xml files in their current xml scheme should be generated. The existing xml files map the syscall names to syscall numbers, and that necessarily need to be per-architecture. I'm super fine with adding the "groups" attribute to each arch file. But we can centralize that. It does not have to be a complicated thing at all. Something like: - rename the existing files: $arch-linux.xml -> $arch-xml.in - add a simple linux-defaults file, containing a simple table, like: ~~~ # First column is syscall name, second column is syscall groups. ... signalfd4 descriptor,signal vfork process ... ~~~ And then add a build step that with a simple perl/python/awk/sed/whatever script goes over each line of that table and seds each $arch-linux-xml.in the file transforming: name="$first_column" into name="$first_column" groups="$second_column" etc. E.g., from: to: That is, a simple text substitution. This makes is much easier to - review - maintain - extend for future syscalls / groups - extend for future architectures than the same info in 14 (and counting) different files, probably all in agreement with each other, but pretty much unverifiable. > In sum: I propose we go ahead now ("don't let the perfect be the enemy > of the good"), and concentrate on the XML problem later. I'd like to hear what Gabriel thinks (both of my questions in the previous email, and this one). If there are grouping differences between the architectures (other than which syscalls are wired/supported), Gabriel will have noticed them, but that knowledge is lost (not encoded anywhere) in the current form. As a quick experiment, I did (which Gabriel's grouping patches applied): $ cat amd64-linux.xml | sed 's/ number=\"[0-9]*\"//g' | sort > amd64-linux-no-number.xml $ cat ppc-linux.xml | sed 's/ number=\"[0-9]*\"//g' | sort > ppc-linux-no-number.xml $ diff -up amd64-linux-no-number.xml ppc-linux-no-number.xml and saw no difference in the grouping, but I did not do that for all archs. Thanks, Pedro Alves