From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36392 invoked by alias); 24 Jul 2015 09:53:38 -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 36377 invoked by uid 89); 24 Jul 2015 09:53:37 -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; Fri, 24 Jul 2015 09:53:36 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id A030EBDD9A; Fri, 24 Jul 2015 09:53:35 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6O9rYb9008454; Fri, 24 Jul 2015 05:53:34 -0400 Message-ID: <55B20B1D.4020805@redhat.com> Date: Fri, 24 Jul 2015 09:53: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 CC: 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> <55B1718B.10100@redhat.com> <86fv4dhpc2.fsf@gmail.com> In-Reply-To: <86fv4dhpc2.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-07/txt/msg00685.txt.bz2 On 07/24/2015 10:33 AM, Yao Qi wrote: >>> +# Test running programs using extended-remote. >> >> Comment looks stale. Looks like I missed pointing out the same >> in patch #2. >> > > I'll remove it. I find these descriptions useful. Could you instead write something like: "Test restarting programs with the R packet." ? > >> 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.) > > Even GDB refreshes all its state after sending R packet, we still need > some way to test GDB and GDBserver with R packet used. Otherwise, it > will be bit-rotten in the future. Sounds like we're talking past each other. Not sure what I said that made it sounds like that idea would obviate the need for the test -- I think your new test is great. I meant something like gdb itself, around extended_remote_restart, calling into a new function factored out from remote_start_remote. This is because the R packet is documented as having no reply, like 'k', no doubt because it assumes the remote target can really hard reset after the R packet. But let's forget it; hardly worth it to spend time on it right now. > > GDBserver has already had an option --disable-packet, so that we can > extend it to force GDBserver/GDB use R packet. However, I don't think > we use --disable-packet much in our testing, at least I don't. Probably > we can hack native-gdbserver.exp to run tests in a loop and pass > different --disable-packet=FOO to GDBserver in each iteration. Thanks, Pedro Alves