Re: [RFC] Support command "catch syscall" properly on different targets

[Doug Evans <dje at google dot com>]

On Fri, Feb 27, 2015 at 6:23 AM, Yao Qi <qiyaoltc@gmail.com> wrote:
> From: Yao Qi <yao.qi@linaro.org>
>
> Nowadays, "catch syscall" is supported on linux-nat target of
> different gdbarch and inf-ttrace target.  However, in
> breakpoint.c:catch_syscall_command_1, we have this check
>
>    /* Checking if the feature if supported.  */
>    if (gdbarch_get_syscall_number_p (gdbarch) == 0)
>      error (_("The feature 'catch syscall' is not supported on \
> this architecture yet."));
>
> On one hand, gdbarch method get_syscall_number isn't installed on any
> HP-UX targets.  That means users will get such error message even
> syscall catchpoint is supported on HP-UX.  On the other hand, on linux
> remote target (with GDBserver), "catch syscall" isn't supported
> (PR 13585), but no error is emitted:
>
>  (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
>  (gdb) catch syscall close
>  Catchpoint 1 (syscall 'close' [3])
>
> The fix in this patch is to add a new target method
> supports_syscall_catchpoint, so that we can have different
> implementations on different targets.  On inf-ttrace, we
> can simply return one, while on linux-child,
> gdbarch_get_syscall_number_p is called.
>
> With this patch applied, on linux remote target, it becomes:
>
>  (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
>  (gdb) catch syscall close
>  The feature 'catch syscall' is not supported on this target yet.
>
> which looks more reasonable to me.  However, this patch causes some
> regressions in catch-syscall.exp,
>
>  catch syscall nonsense_syscall^M
>  The feature 'catch syscall' is not supported on this target yet.^M
>  (gdb) FAIL: gdb.base/catch-syscall.exp: catch syscall to a nonsense syscall is prohibited
>
> because syscall catchpoint isn't supported on exec target.
> I can move these tests to the place where inferior is created, before
> I go too far, I'd like to hear what do you think of this.

Hi.
Some questions come to mind,
and some not specific to the topic at hand.

1) Do we have a story yet for how to handle differences across
multiple targets/inferiors?
E.g., while not completely supported today, what if I'm
debugging two targets and one supports "catch syscall"
and one doesn't? "break" applies across all inferiors
(though I really don't like this as a default behaviour),
and it would be odd if "catch" didn't work similarly
by default.

We have "thread apply all ...".
We could also have "inferior apply all ...".
E.g., inferior apply all break foo
[I gather itsets can help with this, but I like the consistency.]

"catch syscall" is target(arch)-specific.
Multi-arch doesn't work today (except for special cases),
but we should understand how we want it to work tomorrow.
And similarly for all such target-specific commands.

2) Another issue that comes to mind is "catch syscall"
calls get_current_arch which is based on the current frame
if the inferior is live. If I'm debugging a multi-arch inferior (e.g., cell),
then when I do "catch syscall" I have to be cognizant of which frame
I'm in when I do that. [Right?]

3) Does this mean that I now won't be able to do:

bash$ gdb foo
(gdb) catch syscall open # <-- target == "exec" at this point
(gdb) run