From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3046 invoked by alias); 20 May 2013 17:59:53 -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 3037 invoked by uid 89); 20 May 2013 17:59:53 -0000 X-Spam-SWARE-Status: No, score=-8.2 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 20 May 2013 17:59:33 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4KHxUhm015102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 May 2013 13:59:30 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r4KHxTsU005609; Mon, 20 May 2013 13:59:30 -0400 Message-ID: <519A6480.1010208@redhat.com> Date: Mon, 20 May 2013 17:59:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH 4/7] range stepping: gdb References: <1363006291-13334-1-git-send-email-yao@codesourcery.com> <1363006291-13334-5-git-send-email-yao@codesourcery.com> <51928303.3050407@redhat.com> <51934234.9090707@codesourcery.com> In-Reply-To: <51934234.9090707@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-05/txt/msg00736.txt.bz2 On 05/15/2013 09:07 AM, Yao Qi wrote: >> I dislike the design of using PC checks here too :-/. That >> seems fragile, and potentially inefficient (considering GDB ever >> sending more than one range action per packet, that might end up >> fetching registers for threads unnecessarily). IMO, it's better to have > > Sorry, I don't understand why it is inefficient. I meant, thinking forward, if GDB ever sends 100 vCont;r's in the same packet, checking the PC potentially forces fetching the current registers for 100 threads, if GDB doesn't have them (or no longer has them) cached at that point, with the associated extra RSP rountrips/traffic that causes. It seems better not to have a design that forces this refetch. The fragility aspect was a much stronger concern though. I ran the testsuite with an assertion in remote.c to catch the cases of when the PC would be out of the step range. It caught things like displaced stepping, stepping through the dynamic linker, stepping through inlines, and probably others I don't recall right now. Along with software watchpoints, this made wary of other cases (not controlled by trap_expected) where complex run control might end up requiring the target reporting a stop after a single instruction step even if the thread was in the step range to begin with. -- Pedro Alves