From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33021 invoked by alias); 8 Feb 2018 10:09:35 -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 32998 invoked by uid 89); 8 Feb 2018 10:09:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-20.8 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=qi, H*c:alternative X-HELO: mail-qt0-f181.google.com Received: from mail-qt0-f181.google.com (HELO mail-qt0-f181.google.com) (209.85.216.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Feb 2018 10:09:30 +0000 Received: by mail-qt0-f181.google.com with SMTP id i8so5442132qtj.9 for ; Thu, 08 Feb 2018 02:09:30 -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=zUW63I+ujyVv0MmKomlfuK9KuiWhPRb0c1E4RnbySFw=; b=fokLIc2gBrQlDgtGi60TtffKvdiVA0UuP1ODMje9IpRGgWboSYYlg7QHwtA+IFDkhC 68cqUQOxZAd6udM2SNWfAAL2kRUO/752pAJAqGbBj2UK5pFxkklOdJ7WzTkkkXZrZJhG 7gDoT5KcegDvvEE+59hY8WP0D/Lmh3MHXg26b088T21BSjf/NgqKm/JRmQL0V7iDIMBo la/wDdN8VFMQsimnMY6ZnM4gExGxaSRgyy9ArIgZL+QwiH5AmjE7KBIL+L8tTR1CcCPW XV3nyAtcquiK/QkDTU5/+JhphbskKiWR0kQbUK1YOZfFqM7e9cU01VgEgNyWBIgLlyK5 ixMg== X-Gm-Message-State: APf1xPBdir0TDFya2G+iqOMYj6ldymQnmg9UchHq9cJgsmj1XVakX2Wk 7t6g90Y/D+4l441nXJbvP6+vFOOKzSIOlPsHKbo13mS6 X-Google-Smtp-Source: AH8x226sb1LnwRvaPU84afz4S7kI9uwYryjkWBC48OS6Pl5nybUWMYcOQBQzfji3j3Scfx1UPBGGreXj3oeevR47QTU= X-Received: by 10.237.37.228 with SMTP id y33mr235547qtc.182.1518084568950; Thu, 08 Feb 2018 02:09:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.55.4 with HTTP; Thu, 8 Feb 2018 02:08:58 -0800 (PST) In-Reply-To: <86o9l2jhuf.fsf@gmail.com> References: <1517222676-467-1-git-send-email-omair.javaid@linaro.org> <86607ic75j.fsf@gmail.com> <861si4dgfh.fsf@gmail.com> <86o9l2jhuf.fsf@gmail.com> From: Omair Javaid Date: Thu, 08 Feb 2018 10:09: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/msg00133.txt.bz2 On 6 February 2018 at 19:47, Yao Qi wrote: > 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 > > > > 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 > 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/SourceCode/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/ > git/gdb/target.c:423 > #7 0x0000000000a21025 in kill_if_already_running (from_tty=3D1) at > /home/yao/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/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? > > -- > Yao (=E9=BD=90=E5=B0=A7) > From 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. > Hi Yao, Your patch fixes the issue with openOCD stub. I was a little reluctant to make a generic change with regards to reseting inferior control structure. If there isnt a need to preserve inferior control structure in any case then your change is the right solution. 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) > } > > inf->pending_detach =3D 0; > + /* Reset it. */ > + inf->control =3D {NO_STOP_QUIETLY}; > } > > void >