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: Pedro Alves <palves at redhat dot com>
- To: Gabriel Krisman Bertazi <gabriel at krisman dot be>
- Cc: Sergio Durigan Junior <sergiodj at redhat dot com>, gdb-patches at sourceware dot org, dje at google dot com
- Date: Wed, 06 May 2015 15:38:20 +0100
- 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> <87r3r42e0v dot fsf at redhat dot com> <5540ABF8 dot 4000404 at redhat dot com> <87k2wpt6k6 dot fsf at krisman dot be>
On 05/04/2015 03:33 AM, Gabriel Krisman Bertazi wrote:
> Strace maintains static tables holding syscall names, numbers and group
> information for each architecture separately.
>
> My script parsed those tables and mapped the syscall names in GDB's xmls
> to the group information from strace.
>
>> 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.
>
> I didn't see any difference in group allocation for the same syscall in
> different architectures. So this shouldn't be an issue.
>
> Pedro made two suggestions on how to proceed: (1) keep the information
> in a xml file and teach GDB about it or generate the full xml file
> during the build; (2) keep the group information inside a tabular text
> file and use a simple text substitution to generate the full xml during
> the build.
>
> Personally, even though I'm not a big fan of the XML format in general,
> I dislike option (2) because inserting a tabular text file now feels a
> little clumsy. since we already use XML for syscalls, I think syscall
> groups should be stored similarly.
>
> I plan to send a new version later this week (as soon as I have a break
> From college) that implements Pedro's first suggestion. Now, we keep
> the information inside linux-defaults.xml and have a XSL script to
> performs a join of the information and generate the full XML file.
Sounds great. Thanks!
Thanks,
Pedro Alves