Re: [PATCH] Add proper single-step support for arm-none-eabi

[Yao Qi <qiyaoltc at gmail dot com>]

Elouan Appere <elouan.appere@club-internet.fr> writes:

> I'm currently developing a stub on real hardware, and ARMv6 does not
> support single-step at all (and there's no OS feature to do the work,
> either), therefore I need GDB to do software single-step (like it did
> before commit 750ce8d).

Commit 750ce8d only affects arm-linux target.  It doesn't affect
arm-none-eabi at all.  Nowadays, GDB arm-linux target still doesn't
support "target side" single step (it can be done in hardware or in
software in stub) unless the target tells it does.  The logic here is
that GDB keeps the default behavior unless the target tells it something
different.

>
> This patch indeed changes the single-step behavior on arm-none-eabi,
> but this will match the documentation of "vCont?" (whereas the current
> behavior does not); if stubs rely on the behavior you mentioned for
> efficient single-step behavior, they do not respect the documentation
> (and the respective patches to fix this are trivial).

The packet "vCont?" is about query the supported actions in stub, and
GDB can decide its operations according to the supported actions.  If
the stub tells GDB that it supports single-step, GDB can still don't use
vCont;s.  The document is about the protocol, not GDB behavior.

Secondly, some stubs may not support vCont at all, instead, they use s
and S packet.  GDB has no idea does the stub support single step or not,
so GDB has to keep its default behavior (in arm-none-eabi, GDB thinks
target supports single-step, in arm-linux, GDB thinks target doesn't
support single-step).

>
> Conversely, existing compliant stubs (on ARMv6 and older platforms,
> for example) may have been broken by 750ce8d ("Support single step by
> arch or target"), since they were rightfully expecting gdb to perform
> software single-step itself. My patch restores compatibility for
> these.

As I mentioned above, commit 750ce8d still keeps the GDB behavior
unchanged, unless the stub tells GDB that it can do something
different.  I can't figure out a case that 750ce8d breaks existing stubs.

>
> Another non-breaking possibilty would be to check whether or not the
> stub replies an error to "vCont;s" (or the deprecated "s" packet), but
> this would then make the "s;S" vCont? kind of reply useless.

We can extend .to_can_do_single_step interface a little to get more
information.  Current .to_can_do_single_step only returns true if we
definitely know the target can do single-step, otherwise return false.
The change .to_can_do_single_step returning tribool (unknown, true and
false).  true/false means we definitely know the target can/can't do
single-step, unknown means we don't know that.  In arm-none-eabi target,
we only use software single step if .to_can_do_single_step returns
false.  In arm-linux target, we only use hardware single step if
.to_can_do_single_step returns true.

-- 
Yao (齐尧)