From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21035 invoked by alias); 23 Jun 2014 13:29:18 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 21010 invoked by uid 89); 23 Jun 2014 13:29:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mexforward.lss.emc.com Received: from mailuogwhop.emc.com (HELO mexforward.lss.emc.com) (168.159.213.141) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 23 Jun 2014 13:29:11 +0000 Received: from hop04-l1d11-si01.isus.emc.com (hop04-l1d11-si01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id s5NDT5wG009954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2014 09:29:05 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 23 Jun 2014 09:28:54 -0400 Received: from usendtaylorx2l.lss.emc.com (usendtaylorx2l.lss.emc.com [10.243.10.188]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id s5NDSsZi019899; Mon, 23 Jun 2014 09:28:54 -0400 Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043) id 650A05CCA4F; Mon, 23 Jun 2014 09:28:53 -0400 (EDT) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l.lss.emc.com (Postfix) with ESMTP id 609DF5CC9BC; Mon, 23 Jun 2014 09:28:53 -0400 (EDT) To: "Frank Ch. Eigler" cc: "gdb@sourceware.org" Subject: Re: gdb remote protocol breakpoints (Z0 command) In-reply-to: References: <20417.1403189074@usendtaylorx2l> Comments: In-reply-to "Frank Ch. Eigler" message dated "Fri, 20 Jun 2014 20:23:23 -0400." Date: Mon, 23 Jun 2014 13:29:00 -0000 Message-ID: <2039.1403530133@usendtaylorx2l> From: David Taylor X-EMM-MHVC: 1 X-RSA-Classifications: DLM_1, public X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00066.txt.bz2 Frank Ch. Eigler wrote: > > David Taylor writes: > > > [...] > > . there is no bytecode operator for setting memory > > . there is no bytecode operator for setting registers > > [...] > > Can you elaborate why you wish to modify state in breakpoint > conditionals? One of the options with Z0 breakpoints is 'persist' -- you can create a breakpoint that sticks around when GDB disconnects. I don't know why I would want a persistent breakpint if it could neither alter state and nor call functions. Things that I envision using them for include . quick and dirty patching before rebuilding . collecting debugging information If you can alter memory you can turn logging / event recording on and off to just collect information in the areas of interest and generate fewer messages / fewer records. I think that pushing the 'conditional' part of the breakpoint to the stub -- with existing limitations -- is very useful. I think that without extensions the 'persistence' and 'command list' parts aren't very useful. I'm curious, how do you envision using the 'persistence' and 'command list' parts given the current limitations?