Re: [PATCH] Fix for GDB failing to interrupt after run when no PID issued by stub

[Omair Javaid <omair dot javaid at linaro dot org>]

On 31 January 2018 at 21:41, Yao Qi <qiyaoltc@gmail.com> wrote:

> Omair Javaid <omair.javaid@linaro.org> writes:
>
> > Here are the steps to reproduce:
> > 1) arm-none-eabi-gdb file-to-debug.elf
> > 2) target remote :3333
>
> "target extended-remote :3333".
>
> > At this stage gdb would have connected and halted successfully.
> > 3) run
> > Issue ctrl + C to interrupt running program and GDB wont be able to stop.
>
> Could you show the log of "set debug remote 1", especially after
> "ctrl-c" is typed.  I want to understand what is going on over these
> packets between GDB and stub, and reproduce it on GDBserver by disabling
> some packets.  This is what I get,
>

Heres the gdb log with run (no other command b/w connection and run):
https://paste.ubuntu.com/26496015/

Heres the gdb log with continue + run (after we issue a continue/interrupt
cycle where inferior PID is set and inferior->control.stop_soon =
NO_STOP_QUIETLY;) https://paste.ubuntu.com/26496048/


>
> (gdb) c
> Continuing.
> Sending packet: $Z0,7ffff7dea940,1#e0...Packet received: OK
> Sending packet: $QPassSignals:#f3...Packet received: OK
> Sending packet: $Hc0#db...Packet received: OK
> Sending packet: $s#73...Packet received: T0506:c0dcffffff7f0000;07:
> c0dcffffff7f0000;10:7f05400000000000;
> Sending packet: $Z0,40057a,1#74...Packet received: OK
> Sending packet: $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;97;#0a...Packet
> received: OK
> Sending packet: $Hcpa410.0#6f...Packet received: E01
> Sending packet: $c#63...^Cremote_pass_ctrlc called
> remote_interrupt called
> Packet received: T0206:ffffffff00000000;07:d8daffffff7f0000;10:
> e05dadf7ff7f0000;
> Sending packet: $qL1200000000000000000#50...Packet received:
>
> Program received signal SIGINT, Interrupt.
> Sending packet: $z0,40057a,1#94...Packet received: OK
>
> In the stop reply from my gdbserver, there is no "thread id" either.  My
> stop reply has expedite registers while OpenOCD doesn't.  I don't think
> this matters here.
>

The situation with OpenOCD happens because we ran and set inferior pid to
null hoping to update it. Later in extended_remote_create_inferior called
buy run command thread pid gets assigned but we are checking
inferior->control.stop_soon
just before we update the pid and thus it remains to STOP_QUIETLY for
lifetime of the inferior as this flag is only altered by attach command
handlers or during call of clear_proceed_status


>
> --
> Yao (齐尧)
>