From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12268 invoked by alias); 25 Jan 2013 10:44:22 -0000 Received: (qmail 12257 invoked by uid 22791); 25 Jan 2013 10:44:21 -0000 X-SWARE-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,TW_EG X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 25 Jan 2013 10:43:37 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1Tygky-0005tS-HU from Yao_Qi@mentor.com ; Fri, 25 Jan 2013 02:43:36 -0800 Received: from SVR-ORW-FEM-02.mgc.mentorg.com ([147.34.96.206]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jan 2013 02:43:36 -0800 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.1.289.1; Fri, 25 Jan 2013 02:43:34 -0800 Message-ID: <510261A5.1080200@codesourcery.com> Date: Fri, 25 Jan 2013 10:44:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Pedro Alves CC: Subject: Re: [PATCH 1/2] Fix error when GDB connects to GDBserver with qC disabled References: <1358930116-29038-1-git-send-email-yao@codesourcery.com> <510169A9.7090002@redhat.com> In-Reply-To: <510169A9.7090002@redhat.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes 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 X-SW-Source: 2013-01/txt/msg00620.txt.bz2 On 01/25/2013 01:04 AM, Pedro Alves wrote: > First, this removes the remote_notice_new_inferior call in > the case the target doesn't send any expedited registers. > That is, the call is conditional on "if (stop_reply->regcache)". > My intention was to move "remote_notice_new_inferior" before the block "if (stop_reply->regcache)". Don't know why moved it into the block. > Second, the point of the get_thread_arch_regcache call is to > pre-fill the regcache with the expedite register values, before > any other code needs one of the likely registers in the expedited > set (usually PC, SP, FP), thus saving a roundtrip. > I haven't checked if notice_new_inferior (the core function) ends > needing to fetch up registers; it's possible it ends up fetching > the whole g set anyway, but still, it doesn't feel right. So the rationale here is to prefer to use expedite registers in the stop reply, and postpone or even avoid fetching the whole registers by 'g' packet, right? > > This means that if we have a "Txx thread: ptid" reply, then we > don't really need qC... That's what the patch below does. > The patch still tries qC first, but I'm thinking we can flip that > around, and only try qC if the stop reply didn't include a thread. Why don't we do in this way? > /* Query the remote target for which is the current thread/process, > add it to our tables, and update INFERIOR_PTID. The caller is > responsible for setting the state such that the remote end is ready > - to return the current thread. */ > + to return the current thread. > + > + This function is called after handling the '?' or 'vRun' packets, > + whose response is a stop reply from which we can also try > + extracting the thread. If the target doesn't support the explicit > + qC query, we infer the current thread from that stop reply, passed > + in in WAIT_STATUS, which may be NULL. */ redundant "in"? The patch looks right to me. Thanks. -- Yao (齐尧)