Re: [PATCH 1/4] 'catch syscall' feature -- Architecture-independent part

[Tom Tromey <tromey at redhat dot com>]

>>>>> "SÃrgio" == SÃrgio Durigan JÃnior <sergiodj@linux.vnet.ibm.com> writes:

SÃrgio> +    case bp_catch_syscall:
SÃrgio> +      annotate_catchpoint (b->number);
SÃrgio> +      printf_filtered (_("\nCatchpoint %d (%s syscall '%s ()'), "),
SÃrgio> +		       b->number,
SÃrgio> +                       (th_info->syscall_state == TARGET_WAITKIND_SYSCALL_ENTRY)
SÃrgio> +                        ? "called" : "returned from",
SÃrgio> +		       gdbarch_syscall_name_from_number (current_gdbarch,
SÃrgio> +                                                         b->syscall_number));

I think gdbarch_syscall_name_from_number can return NULL.  This could
happen if the kernel adds a new syscall that is not yet known by gdb.
In this case, I think it would be better to print "syscall 1234".

In a similar vein, perhaps "catch syscall 1234" ought to work?
This could be handled in the target-independent code.

Also, instead of "called" here, how about "entering" or "calling"?
Or maybe this is too pedantic ;)


strace has some handy pre-defined groups of syscalls.  I wonder
whether that is something we want?  (This is something that could
comfortably be put off for a future patch.)

Similarly, should it be possible to catch multiple syscalls with a
single catch?  It seems to me that this would be handy for attaching
commands (and conditions) to several calls at once:

    catch syscall read write 1234

This would require some (minor) changes to the internals.

Insofar as I understand it, I like the rest of your patch.

Tom