catch-syscall and XML - Initial thoughts

[Sérgio Durigan Júnior <sergiodj at linux dot vnet dot ibm dot com>]

Ahoy, me hearties!

To start this discussion, I'd like to share my initial thoughts about
how to organize the XML stuff in GDB's tree with you.

1) Runtime x Compile time

As I said in the call, Thiago and I were discussing this topic a little
and we think that the best approach is to read the XML file at runtime.
This way, as Tom noted in #gdb, we could extend GDB (i.e., modify the
syscall's XML file) without having to recompile it at all.

Initially, we would read the entire XML file on demand, that is, when
the user asks for a syscall name/number. I still don't know how much
time will be needed to do this, but I don't think it will be that slow.
After that, we'd be able to use the file in memory, and perform tasks
like converting syscalls names to number (and vice versa).

2) Location of this file

This is a question that I've been wondering for a while. I think that
the correct location would be in a new gdb/syscalls directory, where
we'd put the XML files for each supported architecture. A guy (I don't
remember who) at #gdb asked me to put the files outside gdb/, in a
directory called libsyscall. I don't think that's a good idea (at least
for now) because I'm not aiming to extend this patch to a library.

3) Syntax

Since Daniel said that it'd be good to be able to extend this feature to
support syscalls arguments and types, I think this syntax would be
convenient:

<syscall number="1" name="foo">
	<arg name="arg_name" number="0" type="arg_type"/>
	...
	<arg name="arg_name" number="n" type="arg_type"/>
</syscall>

Initially the catch-syscall feature would only use the syscall name and
number info, but of course in a future not so distant we'd start using
the args info.


So, what do you think? I'd really appreciate opinions :-)

Regards,

-- 
Sérgio Durigan Júnior
Linux on Power Toolchain - Software Engineer
Linux Technology Center - LTC
IBM Brazil