Re: [RFA] arm-pikeos: software single step

[Pedro Alves <palves@redhat.com>]

On 09/11/2018 09:57 PM, Joel Brobecker wrote:
> Hi again Pedro,
> 
>>> Unfortunately, the problem is that we do not control the stub (muxa),
>>> it is a tool that the vendor provides.
>>
>> Did you check whether it is already reporting the RSP packets as I
>> had suggested?  We wouldn't be adding new packets, but instead using
>> some that are already defined.
>>
>> If the stub really needs modification, I'm not opposed to your patch
>> as stop gap.  Would there be any chance to forward the information to
>> the sysgo folks, see if they're willing to tweak the stub?  It should
>> be a trivial change.
> 
> So, here is what I could gather (full log at the end of this email [1]).
> GDB sends the $qSupported packet, equiring about support...
> 
>     | Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df...Ack
> 
> ... and the list returned is fairly small, as I suspected:
> 
>     | Packet received: qXfer:features:read+
> 
> After that, I don't see very much happening at the vCont level,
> so fast-forward to the first "cont" command (after having inserted
> a breakpoint), and we see some interesting stuff. In particular,
> GDB asks the target what vCont support it provides, and here is
> what we receive:
> 
>     | Sending packet: $vCont?#49...Ack
>     | Packet received: vCont;c;s;C;S
>     | Packet vCont (verbose-resume) is supported
> 
> Hah! So, on the one end, the stub says stepping is supported
> ('s' and 'S'), but on the other hand we were told that this
> feature is not supported on ARM.
> 
> So, if I understand correctly the current situation, we do have
> one small infrastructure adjustment to do in GDB, but then once
> done, if the stub on advertised support for "vCont;c;C", then
> GDB would automatically be switching to software single step.
> Do I understand correctly?

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

> 
> If that's correct, I'll make sure AdaCore forwards the suggestion
> to Sysgo.
> 
> Thanks!
Thanks,
Pedro Alves