From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28031 invoked by alias); 12 Jan 2012 19:44:11 -0000 Received: (qmail 28021 invoked by uid 22791); 12 Jan 2012 19:44:10 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 12 Jan 2012 19:43:50 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0CJhkAh026734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jan 2012 14:43:46 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q0CJhjww000576; Thu, 12 Jan 2012 14:43:45 -0500 Message-ID: <4F0F37F0.1000006@redhat.com> Date: Thu, 12 Jan 2012 19:54:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: "Gustavo, Luis" CC: gdb-patches@sourceware.org Subject: Re: [RFC stub-side break conditions 1/5] Documentation bits References: <4F05BA03.1010203@mentor.com> <4F071FAD.9050303@gmail.com> <4F072A67.3030202@mentor.com> In-Reply-To: <4F072A67.3030202@mentor.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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: 2012-01/txt/msg00428.txt.bz2 On 01/06/2012 05:07 PM, Luis Machado wrote: > On 01/06/2012 02:22 PM, Pedro Alves wrote: >> On 01/05/2012 02:56 PM, Luis Machado wrote: >>> +@item @code{conditional-breakpoints-packet} >>> +@tab @code{Z0 and Z1} >>> +@tab @code{Support for stub-side breakpoint condition evaluation} >>> @end multitable >> >> What about watchpoints, and other Z packets? > I wasn't going to touch them for now, but i suppose they can be easily extended later on. If you handled them now, we'd avoid a new qSupported feature later on. :-) >>> @node Remote Stub >>> @@ -34149,7 +34206,7 @@ avoid potential problems with duplicate >>> be implemented in an idempotent way.} >>> >>> @item z0,@var{addr},@var{kind} >>> -@itemx Z0,@var{addr},@var{kind} >>> +@itemx Z0,@var{addr},@var{kind};@r{[};@var{cond expr}@r{]}@dots{} >>> @cindex @samp{z0} packet >> >> That seems to renders as ‘Z0,addr,kind;[;cond expr]...’ > Not right, i'll fix it in the next iteration after clearing the packet format issue. > >> >> Hmm. If we're reusing/extending Z packets, then I'd rather this doesn't >> make it hard to support future extensions to the packet (e.g., thread specific >> breakpoints), while at the same time _not_ supporting stub-side >> condition evaluation. So imagine that I'll add a new thread-id (pPID.TID) >> field to this packet, and I will specify an empty condition. How will the >> result look like? >> >> Z0,addr,kind;;pPID.TID >> >> ? >> >> Wouldn't it be better something like: >> >> Z0,addr,kind,cond_expr_list,other_future_extensions’ >> >> and cond_expr_list being a ;-separated list? > > Makes sense. The problem is that each conditional expression is of the form "size,expr". Where does the ',' requisite come from? Can't we use something else (e.g. ':' or '.')? What happens if we have a field in the future that wants a ';' ? We run out of separator characters. :-) > That's why i used a different marker to signal the beginning of an extension area. > > We could name each extension with a marker (cond, thread_id, itset etc...). Would it be too much overhead in the packet? Like the following. Might make sense, no strong opinion. > Z0,addr,kind,cond=size0,expr0;size1,expr1;...;sizen,exprn,itset=,foo=... > > Something that comes to mind regarding adding multiple extensions to these packets is the packet size limitation. We may have to add "continuation" packets if the extensions get too numerous. If that happens, it probably wouldn't be wise to rely on specific field ordering. >