Re: [PATCH v3 00/17] Catch syscall group

[Gabriel Krisman Bertazi <gabriel@krisman.be>]

[-- Attachment #1: Type: text/plain, Size: 1667 bytes --]

Pedro Alves <palves@redhat.com> writes:

>> 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!

I have a question before sending the new version.

I noticed that the GDB build step currently doesn't depend on xsltproc.
It is used only in gdb/features/Makefile to generate some .dat files,
that are also included in the repository at gdb/regformat.  Am I right?

At first, I intended to use xsltproc as a build step and only provide
the *.xml.in files in the repository.  But that would have the side
effect of forcing xsltproc to be available at build time, and I don't
know if is acceptable.

Other possibility would be to also push the generated files to the
repository.  We'd keep them in gdb/syscalls/generated/, or something
like that, and have a script to update the xmls when needed.

What do you think is the best approach here?

-- 
Gabriel Krisman Bertazi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]