This is the mail archive of the
mailing list for the Archer project.
Re: [PATCH 1/4] 'catch syscall' feature -- Architecture-independent part
- From: Tom Tromey <tromey at redhat dot com>
- To: SÃrgio Durigan JÃnior<sergiodj at linux dot vnet dot ibm dot com>
- Cc: Project Archer <archer at sourceware dot org>
- Date: Mon, 13 Oct 2008 14:06:15 -0600
- Subject: Re: [PATCH 1/4] 'catch syscall' feature -- Architecture-independent part
- References: <1222799270.30389.33.camel@miki>
- Reply-to: Tom Tromey <tromey at redhat dot com>
>>>>> "SÃrgio" == SÃrgio Durigan JÃnior <firstname.lastname@example.org> 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.