gdb ignoring vCont supported commands

gdb ignoring vCont supported commands

[Bill Morgan]

I tell gdb that I support only vCont c and C, so it sends me s. Why is it
sending s when I don't support that?

(gdb) s
Sending packet:
$QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;97;#0a...Ack
Packet received: OK
Sending packet: $vCont?#49...Ack
Packet received: vCont;c;C
Packet vCont (verbose-resume) is supported
Sending packet: $vCont;s:13;c#f4...Ack
Packet received: E01
warning: Remote failure reply: E01

Re: gdb ignoring vCont supported commands

[Pedro Alves]

On 10/09/2018 02:42 PM, Bill Morgan wrote:
> I tell gdb that I support only vCont c and C, so it sends me s. Why is it
> sending s when I don't support that?
> 
> (gdb) s
> Sending packet:
> $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;97;#0a...Ack
> Packet received: OK
> Sending packet: $vCont?#49...Ack
> Packet received: vCont;c;C
> Packet vCont (verbose-resume) is supported
> Sending packet: $vCont;s:13;c#f4...Ack
> Packet received: E01
> warning: Remote failure reply: E01

That's historical behavior, and GDB cannot change it, unfortunately.
But the good news is that in more recent GDBs there is a protocol
extension to tell GDB to trust the set of reported supported
vCont actions.

Copying what I said here:
https://sourceware.org/ml/gdb-patches/2018-09/msg00359.html

~~~~~~~~~~~~~~~~~~~~~~~~
GDB can't trust "vCont;c;C" alone, because for a long
while GDBserver would send "vCont;c;s;C;S" even if the target
did not support hardware stepping.  So what a stub needs to do
is:

Return "vCont;c;C" to "vCont?" _AND_ include "vContSupported"
in the reported "qSupported" features.  The latter tells GDB
to trust that the actions included in "vCont?" are really the
supported ones.  (I wish we had implemented this a little bit
differently, but that ship has sailed, and although a bit
cumbersome, it works.)
~~~~~~~~~~~~~~~~~~~~~~~~

Thanks,
Pedro Alves

Re: gdb ignoring vCont supported commands

[Bill Morgan]

On Tue, Oct 9, 2018 at 1:30 PM Pedro Alves <palves@redhat.com> wrote:

> On 10/09/2018 02:42 PM, Bill Morgan wrote:
> > I tell gdb that I support only vCont c and C, so it sends me s. Why is it
> > sending s when I don't support that?
> >
> > (gdb) s
> > Sending packet:
> > $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;97;#0a...Ack
> > Packet received: OK
> > Sending packet: $vCont?#49...Ack
> > Packet received: vCont;c;C
> > Packet vCont (verbose-resume) is supported
> > Sending packet: $vCont;s:13;c#f4...Ack
> > Packet received: E01
> > warning: Remote failure reply: E01
>
> That's historical behavior, and GDB cannot change it, unfortunately.
> But the good news is that in more recent GDBs there is a protocol
> extension to tell GDB to trust the set of reported supported
> vCont actions.
>
> Copying what I said here:
> https://sourceware.org/ml/gdb-patches/2018-09/msg00359.html
>
> ~~~~~~~~~~~~~~~~~~~~~~~~
> GDB can't trust "vCont;c;C" alone, because for a long
> while GDBserver would send "vCont;c;s;C;S" even if the target
> did not support hardware stepping.  So what a stub needs to do
> is:
>
> Return "vCont;c;C" to "vCont?" _AND_ include "vContSupported"
> in the reported "qSupported" features.  The latter tells GDB
> to trust that the actions included in "vCont?" are really the
> supported ones.  (I wish we had implemented this a little bit
> differently, but that ship has sailed, and although a bit
> cumbersome, it works.)
> ~~~~~~~~~~~~~~~~~~~~~~~~
>
>
I get a warning that vContSupported is unrecognized:

Sending packet:
$qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df...Ack
Packet received:
PacketSize=3fff;QPassSignals+;qXfer:features:read+;qXfer:threads:read+;vContSupported
Packet qSupported (supported-packets) is supported
warning: unrecognized item "vContSupported" in "qSupported" response

I am using this version:

GNU gdb (GNU Tools for Arm Embedded Processors 7-2017-q4-major)
8.0.50.20171128-git



> Thanks,
> Pedro Alves
>

Re: gdb ignoring vCont supported commands

[Simon Marchi]

On 2018-10-09 16:12, Bill Morgan wrote:
> I get a warning that vContSupported is unrecognized:
> 
> Sending packet:
> $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df...Ack
> Packet received:
> PacketSize=3fff;QPassSignals+;qXfer:features:read+;qXfer:threads:read+;vContSupported
> Packet qSupported (supported-packets) is supported
> warning: unrecognized item "vContSupported" in "qSupported" response

I believe you are missing the + after vContSupported.

Simon

Re: gdb ignoring vCont supported commands

[Bill Morgan]

On Tue, Oct 9, 2018 at 3:16 PM Simon Marchi <simon.marchi@polymtl.ca> wrote:

> On 2018-10-09 16:12, Bill Morgan wrote:
> > I get a warning that vContSupported is unrecognized:
> >
> > Sending packet:
> >
> $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df...Ack
> > Packet received:
> >
> PacketSize=3fff;QPassSignals+;qXfer:features:read+;qXfer:threads:read+;vContSupported
> > Packet qSupported (supported-packets) is supported
> > warning: unrecognized item "vContSupported" in "qSupported" response
>
> I believe you are missing the + after vContSupported.
>
> You are correct, I was missing the +. Thank you.

So it is now recognizing the vContSupported, but it is still sending
vCont;s

Sending packet:
$qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df...Ack
Packet received:
PacketSize=3fff;QPassSignals+;qXfer:features:read+;qXfer:threads:read+;vContSupported+
Packet qSupported (supported-packets) is supported

<snip>

Sending packet: $vCont?#49...Ack
Packet received: vCont;c;C
Packet vCont (verbose-resume) is supported

<snip>

(gdb) s
Sending packet: $QPassSignals:#f3...Ack
Packet received: OK
Sending packet: $vCont;s:13#56...Ack
Packet received: E01
warning: Remote failure reply: E01


Simon
>

Re: gdb ignoring vCont supported commands

[Pedro Alves]

On 10/09/2018 09:29 PM, Bill Morgan wrote:
> On Tue, Oct 9, 2018 at 3:16 PM Simon Marchi <simon.marchi@polymtl.ca> wrote:
> 
>> On 2018-10-09 16:12, Bill Morgan wrote:
>>> I get a warning that vContSupported is unrecognized:
>>>
>>> Sending packet:
>>>
>> $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df...Ack
>>> Packet received:
>>>
>> PacketSize=3fff;QPassSignals+;qXfer:features:read+;qXfer:threads:read+;vContSupported
>>> Packet qSupported (supported-packets) is supported
>>> warning: unrecognized item "vContSupported" in "qSupported" response
>>
>> I believe you are missing the + after vContSupported.
>>
>> You are correct, I was missing the +. Thank you.
> 
> So it is now recognizing the vContSupported, but it is still sending
> vCont;s
> 

Argh, I forgot that this only really works on ARM GNU/Linux.
What is your target?

We're missing the small infrastructure change in GDB 
mentioned in the discussion I linked before.

Thanks,
Pedro Alves

Re: gdb ignoring vCont supported commands

[Bill Morgan]

On Tue, Oct 9, 2018 at 4:12 PM Pedro Alves <palves@redhat.com> wrote:

> On 10/09/2018 09:29 PM, Bill Morgan wrote:
> > On Tue, Oct 9, 2018 at 3:16 PM Simon Marchi <simon.marchi@polymtl.ca>
> wrote:
> >
> >> On 2018-10-09 16:12, Bill Morgan wrote:
> >>> I get a warning that vContSupported is unrecognized:
> >>>
> >>> Sending packet:
> >>>
> >>
> $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df...Ack
> >>> Packet received:
> >>>
> >>
> PacketSize=3fff;QPassSignals+;qXfer:features:read+;qXfer:threads:read+;vContSupported
> >>> Packet qSupported (supported-packets) is supported
> >>> warning: unrecognized item "vContSupported" in "qSupported" response
> >>
> >> I believe you are missing the + after vContSupported.
> >>
> >> You are correct, I was missing the +. Thank you.
> >
> > So it is now recognizing the vContSupported, but it is still sending
> > vCont;s
> >
>
> Argh, I forgot that this only really works on ARM GNU/Linux.
> What is your target?
>

Custom OS on ARM.

This is what I'm reporting to GDB:

Sending packet: $qXfer:features:read:target.xml:0,fff#7d...Ack
Packet received: l<target><architecture>arm</architecture></target>



>
> We're missing the small infrastructure change in GDB
> mentioned in the discussion I linked before.
>
> Thanks,
> Pedro Alves
>

Re: gdb ignoring vCont supported commands

[Bill Morgan]

On Tue, Oct 9, 2018 at 4:16 PM Bill Morgan <arthurwilliammorgan@gmail.com>
wrote:

>
>
> On Tue, Oct 9, 2018 at 4:12 PM Pedro Alves <palves@redhat.com> wrote:
>
>> On 10/09/2018 09:29 PM, Bill Morgan wrote:
>> > On Tue, Oct 9, 2018 at 3:16 PM Simon Marchi <simon.marchi@polymtl.ca>
>> wrote:
>> >
>> >> On 2018-10-09 16:12, Bill Morgan wrote:
>> >>> I get a warning that vContSupported is unrecognized:
>> >>>
>> >>> Sending packet:
>> >>>
>> >>
>> $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df...Ack
>> >>> Packet received:
>> >>>
>> >>
>> PacketSize=3fff;QPassSignals+;qXfer:features:read+;qXfer:threads:read+;vContSupported
>> >>> Packet qSupported (supported-packets) is supported
>> >>> warning: unrecognized item "vContSupported" in "qSupported" response
>> >>
>> >> I believe you are missing the + after vContSupported.
>> >>
>> >> You are correct, I was missing the +. Thank you.
>> >
>> > So it is now recognizing the vContSupported, but it is still sending
>> > vCont;s
>> >
>>
>> Argh, I forgot that this only really works on ARM GNU/Linux.
>> What is your target?
>>
>
> Custom OS on ARM.
>
> This is what I'm reporting to GDB:
>
> Sending packet: $qXfer:features:read:target.xml:0,fff#7d...Ack
> Packet received: l<target><architecture>arm</architecture></target>
>
>
>
>>
>> We're missing the small infrastructure change in GDB
>> mentioned in the discussion I linked before.
>>
>
What does GDB need to know about my OS for using software breakpoints for
stepping? From looking at this document:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0036b/IHI0036B_bsabi.pdf
I'd be using the ARM Architecture Procedure Call Standard and probably be
considered Bare Metal. Although I have some ELF processes loaded and
running, I think that should be opaque to GDB though. My stub switches MMU
TTB as necessary for writing the software breakpoints to memory.

Could I report an existing OS to GDB?


>> Thanks,
>> Pedro Alves
>>
>

Re: gdb ignoring vCont supported commands

[Pedro Alves]

On 10/09/2018 10:33 PM, Bill Morgan wrote:
> On Tue, Oct 9, 2018 at 4:16 PM Bill Morgan <arthurwilliammorgan@gmail.com>
> wrote:
> 
>>
>>
>> On Tue, Oct 9, 2018 at 4:12 PM Pedro Alves <palves@redhat.com> wrote:
>>
>>> On 10/09/2018 09:29 PM, Bill Morgan wrote:
>>>> On Tue, Oct 9, 2018 at 3:16 PM Simon Marchi <simon.marchi@polymtl.ca>
>>> wrote:
>>>>
>>>>> On 2018-10-09 16:12, Bill Morgan wrote:
>>>>>> I get a warning that vContSupported is unrecognized:
>>>>>>
>>>>>> Sending packet:
>>>>>>
>>>>>
>>> $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df...Ack
>>>>>> Packet received:
>>>>>>
>>>>>
>>> PacketSize=3fff;QPassSignals+;qXfer:features:read+;qXfer:threads:read+;vContSupported
>>>>>> Packet qSupported (supported-packets) is supported
>>>>>> warning: unrecognized item "vContSupported" in "qSupported" response
>>>>>
>>>>> I believe you are missing the + after vContSupported.
>>>>>
>>>>> You are correct, I was missing the +. Thank you.
>>>>
>>>> So it is now recognizing the vContSupported, but it is still sending
>>>> vCont;s
>>>>
>>>
>>> Argh, I forgot that this only really works on ARM GNU/Linux.
>>> What is your target?
>>>
>>
>> Custom OS on ARM.
>>
>> This is what I'm reporting to GDB:
>>
>> Sending packet: $qXfer:features:read:target.xml:0,fff#7d...Ack
>> Packet received: l<target><architecture>arm</architecture></target>
>>
>>
>>
>>>
>>> We're missing the small infrastructure change in GDB
>>> mentioned in the discussion I linked before.
>>>
>>
> What does GDB need to know about my OS for using software breakpoints for
> stepping? From looking at this document:
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0036b/IHI0036B_bsabi.pdf
> I'd be using the ARM Architecture Procedure Call Standard and probably be
> considered Bare Metal. Although I have some ELF processes loaded and
> running, I think that should be opaque to GDB though. My stub switches MMU
> TTB as necessary for writing the software breakpoints to memory.
> 
> Could I report an existing OS to GDB?

You could try using a --target=arm-linux-gnu GDB (or an --enablet-targets=all)
build, and forcing GNU/Linux ABI, with "set osabi GNU/Linux".  I think
that should be enough.  If that works, you could also report that automatically
in the tdesc, with:

  <osabi>GNU/Linux</osabi>

Of course, that's a hack.  As discussed on the other thread, GDB should
be able to fallback to software single-step automatically.
With the hack, some things might not work correctly, as GDB will be assuming
a GNU/Linux environment in your target.  But maybe it's still good enough.

Thanks,
Pedro Alves

Re: gdb ignoring vCont supported commands

[Bill Morgan]

On Fri, Oct 19, 2018 at 8:40 AM Pedro Alves <palves@redhat.com> wrote:

> On 10/09/2018 10:33 PM, Bill Morgan wrote:
> > On Tue, Oct 9, 2018 at 4:16 PM Bill Morgan <
> arthurwilliammorgan@gmail.com>
> > wrote:
> >
> >>
> >>
> >> On Tue, Oct 9, 2018 at 4:12 PM Pedro Alves <palves@redhat.com> wrote:
> >>
> >>> On 10/09/2018 09:29 PM, Bill Morgan wrote:
> >>>> On Tue, Oct 9, 2018 at 3:16 PM Simon Marchi <simon.marchi@polymtl.ca>
> >>> wrote:
> >>>>
> >>>>> On 2018-10-09 16:12, Bill Morgan wrote:
> >>>>>> I get a warning that vContSupported is unrecognized:
> >>>>>>
> >>>>>> Sending packet:
> >>>>>>
> >>>>>
> >>>
> $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df...Ack
> >>>>>> Packet received:
> >>>>>>
> >>>>>
> >>>
> PacketSize=3fff;QPassSignals+;qXfer:features:read+;qXfer:threads:read+;vContSupported
> >>>>>> Packet qSupported (supported-packets) is supported
> >>>>>> warning: unrecognized item "vContSupported" in "qSupported" response
> >>>>>
> >>>>> I believe you are missing the + after vContSupported.
> >>>>>
> >>>>> You are correct, I was missing the +. Thank you.
> >>>>
> >>>> So it is now recognizing the vContSupported, but it is still sending
> >>>> vCont;s
> >>>>
> >>>
> >>> Argh, I forgot that this only really works on ARM GNU/Linux.
> >>> What is your target?
> >>>
> >>
> >> Custom OS on ARM.
> >>
> >> This is what I'm reporting to GDB:
> >>
> >> Sending packet: $qXfer:features:read:target.xml:0,fff#7d...Ack
> >> Packet received: l<target><architecture>arm</architecture></target>
> >>
> >>
> >>
> >>>
> >>> We're missing the small infrastructure change in GDB
> >>> mentioned in the discussion I linked before.
> >>>
> >>
> > What does GDB need to know about my OS for using software breakpoints for
> > stepping? From looking at this document:
> >
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0036b/IHI0036B_bsabi.pdf
> > I'd be using the ARM Architecture Procedure Call Standard and probably be
> > considered Bare Metal. Although I have some ELF processes loaded and
> > running, I think that should be opaque to GDB though. My stub switches
> MMU
> > TTB as necessary for writing the software breakpoints to memory.
> >
> > Could I report an existing OS to GDB?
>
> You could try using a --target=arm-linux-gnu GDB (or an
> --enablet-targets=all)
> build, and forcing GNU/Linux ABI, with "set osabi GNU/Linux".  I think
> that should be enough.  If that works, you could also report that
> automatically
> in the tdesc, with:
>
>   <osabi>GNU/Linux</osabi>
>
> Of course, that's a hack.  As discussed on the other thread, GDB should
> be able to fallback to software single-step automatically.
> With the hack, some things might not work correctly, as GDB will be
> assuming
> a GNU/Linux environment in your target.  But maybe it's still good enough.
>
> Thanks,
> Pedro Alves
>

OK thanks Pedro. I will probably stick with the patch I posted earlier to
force software stepping for now.

If I have time later maybe I'll try to get a better fix in.

Re: gdb ignoring vCont supported commands

[Bill Morgan]

On Tue, Oct 9, 2018 at 4:12 PM Pedro Alves <palves@redhat.com> wrote:

> On 10/09/2018 09:29 PM, Bill Morgan wrote:
> > So it is now recognizing the vContSupported, but it is still sending
> > vCont;s
> >
>
> Argh, I forgot that this only really works on ARM GNU/Linux.
> What is your target?
>
> We're missing the small infrastructure change in GDB
> mentioned in the discussion I linked before.
>

This looks like the same issue:

https://sourceware.org/bugzilla/show_bug.cgi?id=21272

Re: gdb ignoring vCont supported commands

[Bill Morgan]

On Tue, Oct 9, 2018 at 4:12 PM Pedro Alves <palves@redhat.com> wrote:

> On 10/09/2018 09:29 PM, Bill Morgan wrote:
> >
> > So it is now recognizing the vContSupported, but it is still sending
> > vCont;s
> >
>
> Argh, I forgot that this only really works on ARM GNU/Linux.
> What is your target?
>
> We're missing the small infrastructure change in GDB
> mentioned in the discussion I linked before.
>

I couldn't get the change on the other thread to work, but this has been
reported before and a patch submitted to fix it.

https://sourceware.org/bugzilla/show_bug.cgi?id=21272

I only needed this portion of the patch to get it working.

Any chance on getting it merged to master?

diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
index 53eee76926..721675266c 100644
--- a/gdb/arm-tdep.c
+++ b/gdb/arm-tdep.c
@@ -6221,7 +6221,24 @@ arm_get_next_pcs_addr_bits_remove (struct
arm_get_next_pcs *self,
 static CORE_ADDR
 arm_get_next_pcs_syscall_next_pc (struct arm_get_next_pcs *self)
 {
-  return 0;
+  CORE_ADDR next_pc = 0;
+  CORE_ADDR pc = regcache_read_pc (self->regcache);
+  int is_thumb = arm_is_thumb (self->regcache);
+
+  /* Without the knowledge of the OS (if any) we need to assume that the
next
+     user-mode instruction is executed */
+
+  if (is_thumb)
+    {
+      next_pc = pc + 2;
+    }
+
+  else
+    {
+      next_pc = pc + 4;
+    }
+
+  return next_pc;
 }

 /* Wrapper over arm_is_thumb for use in arm_get_next_pcs.  */
@@ -9384,6 +9401,7 @@ arm_gdbarch_init (struct gdbarch_info info, struct
gdbarch_list *arches)
   set_gdbarch_sw_breakpoint_from_kind (gdbarch,
arm_sw_breakpoint_from_kind);
   set_gdbarch_breakpoint_kind_from_current_state (gdbarch,
    arm_breakpoint_kind_from_current_state);
+  set_gdbarch_software_single_step( gdbarch, arm_software_single_step );

   /* Information about registers, etc.  */
   set_gdbarch_sp_regnum (gdbarch, ARM_SP_REGNUM);

Re: gdb ignoring vCont supported commands

[Pedro Alves]

On 10/18/2018 02:42 PM, Bill Morgan wrote:
> On Tue, Oct 9, 2018 at 4:12 PM Pedro Alves <palves@redhat.com> wrote:
> 
>> On 10/09/2018 09:29 PM, Bill Morgan wrote:
>>>
>>> So it is now recognizing the vContSupported, but it is still sending
>>> vCont;s
>>>
>>
>> Argh, I forgot that this only really works on ARM GNU/Linux.
>> What is your target?
>>
>> We're missing the small infrastructure change in GDB
>> mentioned in the discussion I linked before.
>>
> 
> I couldn't get the change on the other thread to work, 

What change do you mean?

> but this has been
> reported before and a patch submitted to fix it.
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=21272
> 
> I only needed this portion of the patch to get it working.
> 
> Any chance on getting it merged to master?
> 

No, sorry -- that would make gdb always use software single-step,
even if the stub/probe supports hw stepping.

Not sure about the arm_get_next_pcs_syscall_next_pc change,
but I suppose that it helps with most syscalls.

See <https://sourceware.org/gdb/wiki/ContributionChecklist>.

Thanks,
Pedro Alves

Re: gdb ignoring vCont supported commands

[Bill Morgan]

On Fri, Oct 19, 2018 at 8:35 AM Pedro Alves <palves@redhat.com> wrote:

> On 10/18/2018 02:42 PM, Bill Morgan wrote:
> > On Tue, Oct 9, 2018 at 4:12 PM Pedro Alves <palves@redhat.com> wrote:
> >
> >> On 10/09/2018 09:29 PM, Bill Morgan wrote:
> >>>
> >>> So it is now recognizing the vContSupported, but it is still sending
> >>> vCont;s
> >>>
> >>
> >> Argh, I forgot that this only really works on ARM GNU/Linux.
> >> What is your target?
> >>
> >> We're missing the small infrastructure change in GDB
> >> mentioned in the discussion I linked before.
> >>
> >
> > I couldn't get the change on the other thread to work,
>
> What change do you mean?
>
> The change you posted here:
https://sourceware.org/ml/gdb-patches/2018-09/msg00312.html

"The only think missing then I think is moving the only call to

target_can_do_single_step out of the arm-linux-tdep.c file:

 static std::vector<CORE_ADDR>
 arm_linux_software_single_step (struct regcache *regcache)
 {
   struct gdbarch *gdbarch = regcache->arch ();
   struct arm_get_next_pcs next_pcs_ctx;

   /* If the target does have hardware single step, GDB doesn't have
      to bother software single step.  */
   if (target_can_do_single_step () == 1)
     return {};


into somewhere more generic, around infrun.c:maybe_software_singlestep."