From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4367 invoked by alias); 23 Jun 2014 13:14:34 -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 4250 invoked by uid 89); 23 Jun 2014 13:14:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_20,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:14:29 +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 s5NDEON5022715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2014 09:14:24 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 23 Jun 2014 09:14:03 -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 s5NDE3LY032047; Mon, 23 Jun 2014 09:14:03 -0400 Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043) id B3B5D5CCA4F; Mon, 23 Jun 2014 09:14:01 -0400 (EDT) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l.lss.emc.com (Postfix) with ESMTP id 1936D5CC386; Mon, 23 Jun 2014 09:14:01 -0400 (EDT) To: Tom Tromey cc: "gdb@sourceware.org" Subject: Re: gdb remote protocol breakpoints (Z0 command) In-reply-to: <87r42kdd7r.fsf@fleche.redhat.com> References: <20417.1403189074@usendtaylorx2l> <87r42kdd7r.fsf@fleche.redhat.com> Comments: In-reply-to Tom Tromey message dated "Thu, 19 Jun 2014 13:24:40 -0400." Date: Mon, 23 Jun 2014 13:14:00 -0000 Message-ID: <1910.1403529241@usendtaylorx2l> From: David Taylor X-EMM-MHVC: 1 X-RSA-Classifications: public X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00065.txt.bz2 Tom Tromey wrote: > David> There are many things you might want to do at a breakpoint that lack > David> bytecode operators. Just for starters, > [...] > David> . there is no bytecode operator for calling arbitrary functions > > I think this one is a pain to push into the remote, probably why it > wasn't done. It would be reasonable to restrict the number of arguments to a small integer. Another option might be to assume that previous operations have set up the registers and stack and just call that address -- assume that the arguments have already been 'pushed' -- should be doable on most architectures; but, I admit it wouldn't be easy and would involve a fair bit ot GDB work, not just stub work, to make it useful. > David> . there is no 'continue' option (as in: ``after performing the > David> requested commands, continue the current thread'') > > This seems like a different kind of thing altogether. Though I'm not > sure I understand the use case. As a breakpoint condition it could be > done by always returning zero. Sometimes I want to set a breakpoint that does something (e.g., modify variables, call functions) and then continues. For example, if you have an elusive bug, you might want to call a function that collects or prints some debugging information. Our you might want to set a variable -- suppose foo should always be 42 when a particular function is called, but sometimes it is called with other values. If you're involving GDB, you could set a breakpoint with a condition of (foo != 42), and then have commands like: set foo=42 where continue or, if you plan on disconnecting, maybe just set foo=42 continue The more that can be pushed to the target, the fewer round trips that will be required and the less overall impact on the target system performance. Reasons why you might want to do this include -- suppose it takes 5-10 minutes to rebuild and then another 5-10 minutes to download and reboot. So, you're talking 10-20 minutes *plus* whatever time was required to get the system into the current 'misbehaving' state. > David> Has anyone else thought about these issuses and possibly sketched out > David> extensions to allow such capabilities? > > We're looking at extending the "compile" command to add "compile cond", > where the compiled condition is injected into the inferior. This is > still a little ways down the road for us. > > This isn't entirely straightforward, though, and has other tradeoffs. > Also extending agent expressions would be reasonable. I suppose some > feature negotiation here would be needed. > > Tom We aren't yet at the point of implementing condition lists and command lists for the Z0 command for our new stub. It's probably at least a few months off. There's certainly higher priority items on the list.