From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@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:00 -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 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00083.txt.bz2 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 =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=20 > > 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; 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=20 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 =3D {m_pid =3D 643, m_lwp =3D 643, m_tid =3D 0} New value =3D {m_pid =3D 0, m_lwp =3D 643, m_tid =3D 0} 0x0000000000c83ef6 in generic_mourn_inferior () at /home/yao/SourceCode/gnu= /gdb/git/gdb/target.c:3299 3299 inferior_ptid =3D 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=3D0x1839d40 ) at /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:9431 #2 0x0000000000c621f4 in delegate_mourn_inferior (self=3D0x1839d40 ) at /home/yao/SourceCode/gnu/gdb/git/gdb/target-delegates.c:= 1382 #3 0x0000000000c809b6 in target_mourn_inferior (ptid=3D...) at /home/yao/S= ourceCode/gnu/gdb/git/gdb/target.c:2397 #4 0x0000000000b9cd45 in remote_kill (ops=3D0x1839d40 ) at /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:9302 #5 0x0000000000c5fd4e in delegate_kill (self=3D0x1839d40 ) at /home/yao/SourceCode/gnu/gdb/git/gdb/target-delegates.c:1015 #6 0x0000000000c7a905 in target_kill () at /home/yao/SourceCode/gnu/gdb/gi= t/gdb/target.c:423 #7 0x0000000000a21025 in kill_if_already_running (from_tty=3D1) at /home/y= ao/SourceCode/gnu/gdb/git/gdb/infcmd.c:522 #8 0x0000000000a211cd in run_command_1 (args=3D0x0, from_tty=3D1, run_how= =3DRUN_NORMAL) at /home/yao/SourceCode/gnu/gdb/git/gdb/infcmd.c:575 #9 0x0000000000a2183f in run_command (args=3D0x0, from_tty=3D1) at /home/y= ao/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? --=20 Yao (=E9=BD=90=E5=B0=A7) =46rom 854cca001e56dd40f3e5e5118d1e25ffa06a643b Mon Sep 17 00:00:00 2001 From: Yao Qi Date: Tue, 6 Feb 2018 14:45:08 +0000 Subject: [PATCH] Reset inferior::control on inferior exit When we kill an inferior, the inferior is not deleted. What is more, it is reused when the new process is created, so we need to reset inferior's state when it exits. gdb: 2018-02-06 Yao Qi * inferior.c (exit_inferior_1): Reset inf->control. 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) } =20 inf->pending_detach =3D 0; + /* Reset it. */ + inf->control =3D {NO_STOP_QUIETLY}; } =20 void