From patchwork Tue Feb 6 14:47:04 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yao Qi X-Patchwork-Id: 25837 Received: (qmail 16133 invoked by alias); 6 Feb 2018 14:47:18 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 16112 invoked by uid 89); 6 Feb 2018 14:47:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=UD:control.stop_soon, NO_STOP_QUIETLY, H*f:sk:86607ic, sk:clear_p X-HELO: mail-wm0-f67.google.com Received: from mail-wm0-f67.google.com (HELO mail-wm0-f67.google.com) (74.125.82.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 06 Feb 2018 14:47:10 +0000 Received: by mail-wm0-f67.google.com with SMTP id v71so4348488wmv.2 for ; Tue, 06 Feb 2018 06:47:10 -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=MKbuGg2CSlQ/IS4gml8rSpOHH+DtsFe13x33cp6HYss=; b=ncZ7I8oKLWtxWOpKhY8aGh0AHDqJdUpuXNrrPY+/b78Aq8DRFScVoiekJ/watHiR8o ZA8/iWQR7lA80KuQkVWEBOFV8EMQ8E2RAS0CsNqj2E8VeObH9oMOPIOsmqM0HnJ+MAV3 MaAPithHeRWvvUOPC8cEG8p8mPU+gZZZg1nn3ERxDXjNIQb+Y9F2uoVJ/vnjL1ZHvKu/ ZhiMuAq/GEAs35yZJ/7cqzZGWk+v0qWpKWj6d1ow/mA5Md2dj3tto80nconF6TmXyarE kQS8lVh/Xa0L38mx1tRhO9ACOYXPYF7NFhnpVxcHUGzvSKn783PPp4J9HTZiQMHAxIOK Y91Q== X-Gm-Message-State: APf1xPBlAiU/jJmmCUAAnl1PNmKsdZdIdBMApz4D+yEIhbIH0EdLWI27 phtM+2U2403aF4o8cRQkifWsxA== X-Google-Smtp-Source: AH8x225mfe/SCz8LA7s0vAAzQP4FnQrFCks2SqgVy3C0PXHgJ38KJUaPnw/MYebD8TNEHYQ656Lr8g== X-Received: by 10.28.48.10 with SMTP id w10mr2166627wmw.93.1517928428061; Tue, 06 Feb 2018 06:47:08 -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 b72sm9793685wmf.2.2018.02.06.06.47.06 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 06 Feb 2018 06:47:07 -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> <861si4dgfh.fsf@gmail.com> Date: Tue, 06 Feb 2018 14:47:04 +0000 In-Reply-To: (Omair Javaid's message of "Thu, 1 Feb 2018 20:55:27 +0500") Message-ID: <86o9l2jhuf.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 X-IsSubscribed: yes Omair Javaid writes: > 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; Hi Omair, I manged to reproduce it with GDBserver, 1.exe is a simple program calls sleep, $ ./gdbserver/gdbserver --multi :1234 ./1.exe $ ./gdb ./1.exe (gdb) target extended-remote :1234 Remote debugging using :1234 ... 0x00007ffff7ddb2d0 in ?? () from target:/lib64/ld-linux-x86-64.so.2 (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /scratch/yao/gdb/build-git/x86_64/gdb/1.exe Reading /lib64/ld-linux-x86-64.so.2 from remote target... Reading /lib64/ld-linux-x86-64.so.2 from remote target... Reading /lib64/ld-2.19.so from remote target... Reading /lib64/.debug/ld-2.19.so from remote target... Reading /lib/x86_64-linux-gnu/libc.so.6 from remote target... Reading /lib/x86_64-linux-gnu/libc-2.19.so from remote target... Reading /lib/x86_64-linux-gnu/.debug/libc-2.19.so from remote target... ^C This is consistent to the bug reported https://bugs.launchpad.net/gcc-arm-embedded/+bug/1594341 I set watchpoint on inferior->control.stop_soon and inferior_ptid, so I find that inferior_ptid is reset in generic_mourn_inferior, (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Hardware watchpoint 3: inferior_ptid Old value = {m_pid = 643, m_lwp = 643, m_tid = 0} New value = {m_pid = 0, m_lwp = 643, m_tid = 0} 0x0000000000c83ef6 in generic_mourn_inferior () at /home/yao/SourceCode/gnu/gdb/git/gdb/target.c:3299 3299 inferior_ptid = null_ptid; top?bt 10 #0 0x0000000000c83ef6 in generic_mourn_inferior () at /home/yao/SourceCode/gnu/gdb/git/gdb/target.c:3299 #1 0x0000000000b9d1f2 in remote_mourn (target=0x1839d40 ) at /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:9431 #2 0x0000000000c621f4 in delegate_mourn_inferior (self=0x1839d40 ) at /home/yao/SourceCode/gnu/gdb/git/gdb/target-delegates.c:1382 #3 0x0000000000c809b6 in target_mourn_inferior (ptid=...) at /home/yao/SourceCode/gnu/gdb/git/gdb/target.c:2397 #4 0x0000000000b9cd45 in remote_kill (ops=0x1839d40 ) at /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:9302 #5 0x0000000000c5fd4e in delegate_kill (self=0x1839d40 ) at /home/yao/SourceCode/gnu/gdb/git/gdb/target-delegates.c:1015 #6 0x0000000000c7a905 in target_kill () at /home/yao/SourceCode/gnu/gdb/git/gdb/target.c:423 #7 0x0000000000a21025 in kill_if_already_running (from_tty=1) at /home/yao/SourceCode/gnu/gdb/git/gdb/infcmd.c:522 #8 0x0000000000a211cd in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at /home/yao/SourceCode/gnu/gdb/git/gdb/infcmd.c:575 #9 0x0000000000a2183f in run_command (args=0x0, from_tty=1) at /home/yao/SourceCode/gnu/gdb/git/gdb/infcmd.c:688 however, this leads me thinking that why don't we reset inferior too? Note that generic_mourn_inferior calls exit_inferior_1, where various fields of inferior are "reset". The patch below fixes the problem with gdbserver, does it work with you on OpenOCD? diff --git a/gdb/inferior.c b/gdb/inferior.c index 38b7369..880f25d 100644 --- a/gdb/inferior.c +++ b/gdb/inferior.c @@ -224,6 +224,8 @@ exit_inferior_1 (struct inferior *inftoex, int silent) } inf->pending_detach = 0; + /* Reset it. */ + inf->control = {NO_STOP_QUIETLY}; } void