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

[Yao Qi <qiyaoltc at gmail dot com>]

Doug Evans <dje@google.com> writes:

> 1) Do we have a story yet for how to handle differences across
> multiple targets/inferiors?

I don't have such story in my mind.  Taking a look at
https://sourceware.org/gdb/wiki/MultiTarget and I don't see anything on
handling differences across multiple targets.

> 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.

When GDB goes to multi-target, syscall catchpoint should be skipped for
targets don't support it, IMO.

>
> 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.

Oh, multi-arch is supported, isn't?  done by these two patch sets in
both GDB and GDBserver side respectively,

  https://sourceware.org/ml/gdb-patches/2012-11/msg00228.html
  https://sourceware.org/ml/gdb-patches/2013-05/msg01057.html

However, I'd say that multi-arch isn't widely used because it is hard to
find a case that more than one arch can exist in one single target.
Probably once multi-target is supported, multi-arch will be more used.

In the future, IMHO, each command has a scope, a term from itset
patches, and the command is applied to the given scope.  The scope
is a set of targets, inferiors and threads.  If "catch syscall" command
is applied to a scope in which one target doesn't support it, GDB can
report an error like "Target foo in scope bar doesn't support
'catch syscall'".

>
> 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?]

Yeah, I think so.  "catch syscall" support varies on different arches,
and the frames in the same call chain may have different arches.
so "catch syscall" is supported on some frames, and not supported on
other frames.

>
> 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

Yes.

-- 
Yao (éå)