This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v3 00/17] Catch syscall group
- From: Sergio Durigan Junior <sergiodj at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Gabriel Krisman Bertazi <gabriel at krisman dot be>, gdb-patches at sourceware dot org, dje at google dot com
- Date: Tue, 28 Apr 2015 16:28:48 -0400
- Subject: Re: [PATCH v3 00/17] Catch syscall group
- Authentication-results: sourceware.org; auth=none
- References: <1430011521-24340-1-git-send-email-gabriel at krisman dot be> <553F6BC0 dot 9000905 at redhat dot com>
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:
>
> <syscall-defaults name="select" groups="descriptor"/>
> ...
> <syscall-defaults name="openat" groups="descriptor,file"/>
>
> And then the arch-specific syscall files would do:
>
> <xi:include href="linux-defaults.xml"/>
> ...
> <syscall name="select" number="82"/>
> ...
> <syscall name="arch_specific_foo" number="200" groups="descriptor"/>
> ...
>
> And then we teach gdb about syscall-default-groups, or
> we could even instead preprocess the architecture xml to expand
> the groups into each syscall with xsltproc (we already use
> this tool, see gdb/features/Makefile and gdb/features/number-regs.xsl).
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 :-). 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.
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.
Cheers,
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/