From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36144 invoked by alias); 1 Feb 2018 15:56:04 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 33760 invoked by uid 89); 1 Feb 2018 15:56:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=sk:paste.u, pasteubuntucom, paste.ubuntu.com, UD:paste.ubuntu.com X-HELO: mail-qt0-f174.google.com Received: from mail-qt0-f174.google.com (HELO mail-qt0-f174.google.com) (209.85.216.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 01 Feb 2018 15:56:01 +0000 Received: by mail-qt0-f174.google.com with SMTP id o35so26970820qtj.13 for ; Thu, 01 Feb 2018 07:56:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pg4qKLmNMAu1lg1US3n8FrYw6Kmh73RQyUrFQsCVi6c=; b=LpTdk6DWfWb2yjcUZsDhfgePaJUhQwMrfdVJZof4mpQQCgVDcvH63BYByA86LCbltx OPrIeJ6vH5Hs5gKN51zs5UF8wF6oDQ7K7oaA/9tdIx6uXUPZAnixoXw/kKGN+Of31gul FEkYCOQ7PHZQ8bTg5HYt3GOCKICIT5hnTTvSn9ss6lmD/55/loSzldURuyHodAlrsBZA 9VTfpL+0Kw4/g0x9T+mwv7BvD1yg06yHA4NBxLlKnWrOhhH+8Cuzb7J0sYO5P4aHVF4c PGdIKoWt3Lj41QkSJRfvWQdCp/mzMA3rcUfUqmjIP59nCK9g3pIQghpKmsJEzXccSIol MocA== X-Gm-Message-State: AKwxyte5AcsekljqRtFaMvqdidYaAN49GRXduO8HnkGoqBnMIy2Yo5qD aDV7LOtnMAKe+/CTyeUrEadFhvGh/ce91dATbAZG7Q== X-Google-Smtp-Source: AH8x227PDksRczfOVz8tT7SmRxScZLFg4BJmE+o0Dvy1P7kDeA9C5pkF2rjbOTCGW4jKxdeXsBZ1mk3z5JtyQvpAlCA= X-Received: by 10.200.39.173 with SMTP id w42mr59666533qtw.206.1517500557753; Thu, 01 Feb 2018 07:55:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.55.4 with HTTP; Thu, 1 Feb 2018 07:55:27 -0800 (PST) In-Reply-To: <861si4dgfh.fsf@gmail.com> References: <1517222676-467-1-git-send-email-omair.javaid@linaro.org> <86607ic75j.fsf@gmail.com> <861si4dgfh.fsf@gmail.com> From: Omair Javaid Date: Thu, 01 Feb 2018 15:56:00 -0000 Message-ID: Subject: Re: [PATCH] Fix for GDB failing to interrupt after run when no PID issued by stub To: Yao Qi Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00013.txt.bz2 On 1 February 2018 at 17:48, Yao Qi wrote: > Omair Javaid 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\n\n\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 !=3D 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 =3D 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 =3D 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 =3D NO_STOP_QUIETLY;) infrun.c start_remote () line:3223 (inferior->control.stop_soon =3D 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 =3D NO_STOP_QUIETLY; -- > Yao (=E9=BD=90=E5=B0=A7) >