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

[Omair Javaid <omair.javaid@linaro.org>]

On 1 February 2018 at 17:48, Yao Qi <qiyaoltc@gmail.com> wrote:

> Omair Javaid <omair.javaid@linaro.org> writes:
>
> > Heres the gdb log with run (no other command b/w connection and run):
> > https://paste.ubuntu.com/26496015/
> >
>
> One thing suspicious to me is an empty reply to qXfer:threads:read
>
> w $qXfer:threads:read::0,fff#03
> r $l<?xml version="1.0"?>\n<threads>\n</threads>\n#02
>
> OpenOCD claims support "qXfer:threads:read+;", but such reply above may
> confuse GDB.  In OpenOCD source, I find OpenOCD supports qXfer:threads
> unconditionally, but I think it should be changed to support it when
> "target->rtos != NULL".  This may don't matter.
>
> > 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/
> >
>
> >
> > 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
>
> I still don't understand why inferior->control.stop_soon remains
> "STOP_QUIETLY", inferior::control::stop_soon is initialized to
> NO_STOP_QUIETLY.  I even don't see where it is changed to STOP_QUIETLY.
>
> I can understand that GDB check inferior_ptid (try to set
> inferior->control.stop_soon) first [1], and then update inferior_ptid
> later [2],
>
>   if (!have_inferiors ())
>     {
>       /* Clean up from the last time we ran, before we mark the target
>          running again.  This will mark breakpoints uninserted, and
>          get_offsets may insert breakpoints.  */
>       init_thread_list ();
>       init_wait_for_inferior ();  <-- [1]
>     }
>
>   /* vRun's success return is a stop reply.  */
>   stop_reply = run_worked ? rs->buf : NULL;
>   add_current_inferior_and_thread (stop_reply);  <-- [2]
>
> However, current_inferior_ isn't changed at all, and
> current_inferior_->control.stop_soon is not changed either
> (NO_STOP_QUIETLY).  Could you show me where inf->control.stop_soon is
> changed from NO_STOP_QUIETLY?
>
>
Here is the sequence of change to inf->control.stop_soon

gdb) tar ext :3333

infrun.c clear_proceed_status () line: 2903 (inferior->control.stop_soon =
NO_STOP_QUIETLY;)

infrun.c start_remote () line:3223 (inferior->control.stop_soon =
STOP_QUIETLY_REMOTE;)

gdb) run

infcmd.c:575 calls run_command_1 call () which sets PID to null

Further more if we do a continue after connection a call to
clear_proceed_status
with a valid PID will set inferior->control.stop_soon = NO_STOP_QUIETLY;


--
> Yao (齐尧)
>