From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101016 invoked by alias); 1 Feb 2018 12:48:52 -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 100806 invoked by uid 89); 1 Feb 2018 12:48:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy=sk:paste.u, pasteubuntucom, paste.ubuntu.com, UD:paste.ubuntu.com X-HELO: mail-wm0-f50.google.com Received: from mail-wm0-f50.google.com (HELO mail-wm0-f50.google.com) (74.125.82.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 01 Feb 2018 12:48:31 +0000 Received: by mail-wm0-f50.google.com with SMTP id t74so5640542wme.3 for ; Thu, 01 Feb 2018 04:48:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=TdUVtmr1KhjKRNEkQhhxHmJ/2UhbJvOm68oOm4H3ux0=; b=qNW9GR2l9ZBmABNzJbNLmtOpVuT/AVbujJhuddW5SrWGOFgQy0Kmdgni8p1m17lfIt xU3eWQUjl60BnHokhzRM0oFA1i6M5ioaa6pn7q5HlXwjoZiF9gin06CeIf+OZbjpJFKQ G8Xgfidl5lY9Y4x3iVwYQI+p74NWGglxDYPg17jwlMCayrvRhNVHDn2B+wJ3eFomnvrF QUSm+/qO8jQZMMlAN9TfjjnqIQgEkt3secqjwuFw1NqRhMUWNb8S/alzTqk+YTllLQgA LR2w0nZOBfaY/Z7u8eOIpPcreQo4xGr/QuXZCFE6fQ7saGB0FYCyDHb61UOmoHTFRJE1 1FKg== X-Gm-Message-State: AKwxytdgujCwNZoqJ88ks0WtroK1Mb2lH36+99vEOCMq2kBgnhHYoIow +rSz+wo4BejW9SFqzB80TLR+ZA== X-Google-Smtp-Source: AH8x2250eAlzbeLbJOihOlp94G5P88fl9CpiCGznORqskxiRjMGPN3ljRCq9EPxLOcC6oqfU4k5VMw== X-Received: by 10.28.128.136 with SMTP id b130mr25743895wmd.68.1517489302284; Thu, 01 Feb 2018 04:48:22 -0800 (PST) Received: from E107787-LIN (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id i75sm2294005wmg.41.2018.02.01.04.48.21 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 01 Feb 2018 04:48:21 -0800 (PST) From: Yao Qi To: Omair Javaid Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Fix for GDB failing to interrupt after run when no PID issued by stub References: <1517222676-467-1-git-send-email-omair.javaid@linaro.org> <86607ic75j.fsf@gmail.com> Date: Thu, 01 Feb 2018 12:48:00 -0000 In-Reply-To: (Omair Javaid's message of "Wed, 31 Jan 2018 22:00:36 +0500") Message-ID: <861si4dgfh.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00005.txt.bz2 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=20 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? --=20 Yao (=E9=BD=90=E5=B0=A7)