From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4015 invoked by alias); 20 May 2013 18:00:34 -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 4006 invoked by uid 89); 20 May 2013 18:00:34 -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 18:00:33 +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 (8.14.4/8.14.4) with ESMTP id r4KI0VaZ026350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 May 2013 14:00:31 -0400 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 r4KI0TCw005069; Mon, 20 May 2013 14:00:30 -0400 Message-ID: <519A64BD.8030104@redhat.com> Date: Mon, 20 May 2013 18:00: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 3/7] range stepping: gdbserver on x86/linux References: <1363006291-13334-1-git-send-email-yao@codesourcery.com> <1363006291-13334-4-git-send-email-yao@codesourcery.com> <519282CB.4030800@redhat.com> <51933C0B.1060109@codesourcery.com> In-Reply-To: <51933C0B.1060109@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-05/txt/msg00737.txt.bz2 On 05/15/2013 08:40 AM, Yao Qi wrote: > On 05/15/2013 02:30 AM, Pedro Alves wrote: >> - it assumes GDB will ever only send one r action per vCont. I'd much >> rather we don't bake in that assumption. >> > > I am afraid not. It works for multiple r actions in one vCont. Oh, sorry about that. :-/ That wasn't actually the issue I had noticed initially, and then when I went back to compose the email, I had already forgotten and got it mixed up. The issue was actually with: if (end > 0) { struct thread_info *tp = find_thread_ptid (ptid); /* GDB should not send range stepping for all threads of a process, like 'vCont;rSTART,END:pPID.-1', TP can't be NULL. */ gdb_assert (tp != NULL); I think it's best not to error on this as nothing in the protocol actually prohibits it, and we might take advantage of it at some point. The way gdbserver handles vCont requests currently is by letting the target match the ptid to whatever thread/lwp. That means leaving server.c only knowing about how to parse the rsp and construct a thread_resume, and then pass that down to the target. Conceivably, a target might not need to keep the step range anywhere, if it has something like a PTRACE_STEP_RANGE at the kernel level. (There's PTRACE_BLOCKSTEP, but it's not the same). -- Pedro Alves