From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27431 invoked by alias); 21 May 2014 09:02:11 -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 27418 invoked by uid 89); 21 May 2014 09:02:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_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 ESMTP; Wed, 21 May 2014 09:01:43 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4L91fLh001239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 21 May 2014 05:01:41 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s4L91dIe003031; Wed, 21 May 2014 05:01:40 -0400 Message-ID: <537C6B73.60704@redhat.com> Date: Wed, 21 May 2014 09:02:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Yao Qi , gdb-patches@sourceware.org Subject: Re: [PATCH 3/3] [GDBserver] Make Zx/zx packet handling idempotent. References: <1398296475-27997-1-git-send-email-palves@redhat.com> <1398296475-27997-4-git-send-email-palves@redhat.com> <537C0F4A.8060708@codesourcery.com> In-Reply-To: <537C0F4A.8060708@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-05/txt/msg00463.txt.bz2 On 05/21/2014 03:28 AM, Yao Qi wrote: > The patch is good! > > On 04/24/2014 07:41 AM, Pedro Alves wrote: >> So the fix is to generalize mem-break.c to track all kinds of Zx >> breakpoints, and filter out duplicates. As mentioned, this ends up >> adding support for target-side conditions on hardware breakpoints and >> watchpoints too (though GDB itself doesn't support the latter yet). >> > > Can GDBserver returns feature "ConditionalWatchpoints" for qSupported > query now? I think so, yes, though I haven't tried it. (and I'm not planning to, feel free to pick that.) >> As software/memory breakpoints work by poking at memory, when setting >> a GDB Z0 breakpoint (but not internal breakpoints, as those can assume >> the conditions are already right), we need to tell the target to >> prepare to access memory (which on Linux means stop threads). If that >> operation fails, we need to return error to GDB. Seeing an error, if >> this is the first breakpoint of that type that GDB tries to insert, >> GDB would then assume the breakpoint type is supported, but it may >> actually not be. So we need to check whether the type is supported at > > I am confused by this, isn't it "GDB would then assume the breakpoint > type is NOT supported, but it may actually be"? Nope. It's like this: Say Z0 is NOT supported by the target. - GDB sends Z0 - GDBserver asks the backend to prepare to access memory - GDBserver's target backend tries to stop threads or whatever - that fails, and GDBserver returns E01 - GDB interprets that as: "target supports Z0, but something went wrong with inserting the breakpoint, say, e.g., that address is unmapped?" - GDB now "knows" the target supports Z0, so sends another the next time a breakpoint needs to be inserted - This time preparing to access memory actually suceeds, and then GDBserver finds out the target backend actually doesn't support Z0. - GDBserver returns the empty reply, indicating no support for Z0. - GDB hits this error in packet_ok: case PACKET_UNKNOWN: /* The stub does not support the packet. */ if (config->detect == AUTO_BOOLEAN_AUTO && config->support == PACKET_ENABLE) { /* If the stub previously indicated that the packet was supported then there is a protocol error. */ error (_("Protocol error: %s (%s) conflicting enabled responses."), config->name, config->title); } That's why the sequence must be: - GDB sends Z0 - GDBserver checks whether the target backend supports Z0 before actually trying to do anything to the inferior. - The backend says it doesn't support Z0. - GDBserver returns empty reply. -- Pedro Alves