This is the mail archive of the
mailing list for the GDB project.
Re: [RFC] Support command "catch syscall" properly on different targets
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Sergio Durigan Junior <sergiodj at redhat dot com>
- Cc: Yao Qi <qiyaoltc at gmail dot com>, Pedro Alves <palves at redhat dot com>, gdb-patches at sourceware dot org
- Date: Mon, 09 Mar 2015 14:29:11 +0000
- Subject: Re: [RFC] Support command "catch syscall" properly on different targets
- Authentication-results: sourceware.org; auth=none
- References: <1425047015-1906-1-git-send-email-qiyaoltc at gmail dot com> <877fv3kqx1 dot fsf at redhat dot com> <86lhjei8md dot fsf at gmail dot com> <54F5A90E dot 8050704 at redhat dot com> <87bnkaklbe dot fsf at redhat dot com> <868ufahylt dot fsf at gmail dot com> <87lhj9zsss dot fsf at redhat dot com>
Sergio Durigan Junior <firstname.lastname@example.org> writes:
> So, as I said in my previous messages, I don't think that making the
> "catch syscall" command to fail on the exec target.
> What do you think of the attached patch (applies on top of your patch,
> rebased to the current HEAD)? It implements what I proposed, but in a
> different way. If the target is "None" (no binary loaded) or "exec"
> (inferior loaded but never started), then it displays a warning but
> still creates the catchpoint. The actual check for these targets
> happens in the insert_catch_syscall function, which is called when we
> already know if the target actually supports the syscall catchpoint.
> Maybe I forgot to cover some corner case, but I still think we should
> support "catch syscall" when no inferior has been started.
I don't have a strong opinion against your approach. Since "catch
point" is only supported on some arches on linux native target, I think
it is OK to leave gdbarch_get_syscall_number_p checking in
catch_syscall_command_1, so I withdraw my patch.
However, when I play with your patch, I find GDB can disable catch point if it
isn't inserted successfully, in breakpoint.c:insert_bp_location,
else if (bl->owner->type == bp_catchpoint)
gdb_assert (bl->owner->ops != NULL
&& bl->owner->ops->insert_location != NULL);
val = bl->owner->ops->insert_location (bl);
bl->owner->enable_state = bp_disabled;
if (val == 1)
Error inserting catchpoint %d: Your system does not support this type\n\
of catchpoint."), bl->owner->number);
warning (_("Error inserting catchpoint %d."), bl->owner->number);
as shown below,
(gdb) target remote :1234
Remote debugging using :1234
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
0x00007ffff7ddb2d0 in ?? () from /lib64/ld-linux-x86-64.so.2
warning: Error inserting catchpoint 1: Your system does not support this type
(gdb) info breakpoints
Num Type Disp Enb Address What
1 catchpoint keep n syscall "open"
According this observation, I don't see the need check
gdbarch_get_syscall_number_p in catch_syscall_command_1. Probably we
can remove it.