From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51870 invoked by alias); 23 Jul 2015 22:58:27 -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 51853 invoked by uid 89); 23 Jul 2015 22:58:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 23 Jul 2015 22:58:22 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 74EB935B8AC; Thu, 23 Jul 2015 22:58:21 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6NMwKwD016747; Thu, 23 Jul 2015 18:58:20 -0400 Message-ID: <55B1718B.10100@redhat.com> Date: Thu, 23 Jul 2015 22:58:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yao Qi , gdb-patches@sourceware.org Subject: Re: [PATCH 3/8] Set general_thread after restart References: <1437392126-29503-1-git-send-email-yao.qi@linaro.org> <1437392126-29503-4-git-send-email-yao.qi@linaro.org> In-Reply-To: <1437392126-29503-4-git-send-email-yao.qi@linaro.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-07/txt/msg00671.txt.bz2 On 07/20/2015 12:35 PM, Yao Qi wrote: > When I run gdb.server/ext-restart.exp, I get the following GDB internal > error, > > run^M > The program being debugged has been started already.^M > Start it from the beginning? (y or n) y^M > Sending packet: $vKill;53c5#3d...Packet received: OK^M > Packet vKill (kill) is supported^M > Sending packet: $vFile:close:6#b6...Packet received: F0^M > Sending packet: $vFile:close:3#b3...Packet received: F0^M > Starting program: /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.server/ext-restart ^M > Sending packet: $QDisableRandomization:1#cf...Packet received: OK^M > Sending packet: $R0#82...Sending packet: $qC#b4...Packet received: QCp53c5.53c5^M <-- [1] > Sending packet: $qAttached:53c5#c9...Packet received: E01^M > warning: Remote failure reply: E01^M Curious. Kevin's original patch to handle bogus qC replies would have hidden this bug. Plus, today I wrote a patch that exposed a bunch of stale general_thread issues (but not this one). Funny how sometimes we all end up staring at the same things at the same time. > > /* Wait till we are at 1st instruction in prog. */ > if (program_argv != NULL) > - start_inferior (program_argv); > + { > + start_inferior (program_argv); > + general_thread = last_ptid; > + } I think this should be: if (last_status.kind == TARGET_WAITKIND_STOPPED) { /* Stopped at the first instruction of the target process. */ general_thread = last_ptid; } else { /* Something went wrong. */ general_thread = null_ptid; } > +# Test running programs using extended-remote. Comment looks stale. Looks like I missed pointing out the same in patch #2. Otherwise looks good to me. (I think it's likely we have lots of stale-data bugs on the gdb side after R, as we don't resync much. It previously crossed my mind that immediately after sending R, gdb should refresh all its remote state anew, like if it had just disconnected and then reconnected. That is, do most of what remote_start_remote does, except the connection-specific details (qSupported, etc.) Hard to justify the effort though -- I don't think I ever worked with a stub that relies on R.) Thanks, Pedro Alves