From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116704 invoked by alias); 15 Sep 2015 14:51:35 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 116686 invoked by uid 89); 15 Sep 2015 14:51:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 15 Sep 2015 14:51:34 +0000 Received: from svr-orw-fem-05.mgc.mentorg.com ([147.34.97.43]) by relay1.mentorg.com with esmtp id 1ZbrZz-000017-53 from Don_Breazeal@mentor.com ; Tue, 15 Sep 2015 07:51:31 -0700 Received: from [172.30.14.241] (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 15 Sep 2015 07:51:30 -0700 Subject: Re: problem with new vforkdone stop reply in 7.10 To: Pedro Alves References: <55F828D9.8050100@redhat.com> CC: "gdb@sourceware.org" From: Don Breazeal Message-ID: <55F8306D.4010801@codesourcery.com> Date: Tue, 15 Sep 2015 14:51:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55F828D9.8050100@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00005.txt.bz2 On 9/15/2015 7:19 AM, Pedro Alves wrote: > Hi Don, > > Unfortunately, I missed in review that the vforkdone stop reply > misses indicating the thread ID of the vfork parent which the > event relates to: > > @cindex vfork events, remote reply > @item vfork > The packet indicates that @code{vfork} was called, and @var{r} > is the thread ID of the new child process. Refer to > @ref{thread-id syntax} for the format of the @var{thread-id} > field. This packet is only applicable to targets that support > vfork events. > > @cindex vforkdone events, remote reply > @item vforkdone > The packet indicates that a child process created by a vfork > has either called @code{exec} or terminated, so that the > address spaces of the parent and child process are no longer > shared. The @var{r} part is ignored. This packet is only > applicable to targets that support vforkdone events. > > Unfortunately, this is not just a documentation issue. GDBserver > is really not specifying the thread ID. I noticed because > in non-stop mode, gdb complains: > > [Thread 6089.6089] #1 stopped. > #0 0x0000003615a011f0 in ?? () > 0x0000003615a011f0 in ?? () > (gdb) set debug remote 1 > (gdb) c > Continuing. > Sending packet: $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;#5f...Packet received: OK > Sending packet: $vCont;c:p17c9.17c9#88...Packet received: OK > Notification received: Stop:T05vfork:p17ce.17ce;06:40d7ffffff7f0000;07:30d7ffffff7f0000;10:e4c9eb1536000000;thread:p17c9.17c9;core:2; > Sending packet: $vStopped#55...Packet received: OK > Sending packet: $D;17ce#af...Packet received: OK > Sending packet: $vCont;c:p17c9.17c9#88...Packet received: OK > Notification received: Stop:T05vforkdone:; > No process or thread specified in stop reply: T05vforkdone:; > (gdb) > > This is not non-stop-mode-specific, however. Consider e.g., that > in all-stop, you may be debugging more than one process at the > same time. You continue, and both processes vfork. So if you next > a T05vforkdone, how can we tell which of the parent processes > has had its child exit/exec? > > Thanks, > Pedro Alves > Hi Pedro, Thanks for pointing this out. I will take a look at it. This case would make an interesting test. --Don