From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27695 invoked by alias); 23 Oct 2014 15:35:02 -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 27675 invoked by uid 89); 23 Oct 2014 15:35:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,NO_DNS_FOR_FROM,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mailuogwhop.emc.com Received: from mailuogwhop.emc.com (HELO mailuogwhop.emc.com) (168.159.213.141) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 23 Oct 2014 15:35:00 +0000 Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9NFYuZx032675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2014 11:34:57 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s9NFYuZx032675 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s9NFYuZx032675 Received: from mailsyshubprd06.lss.emc.com (mailsyshubprd06.lss.emc.com [10.253.24.24]) by maildlpprd03.lss.emc.com (RSA Interceptor); Thu, 23 Oct 2014 11:34:35 -0400 Received: from usendtaylorx2l.lss.emc.com (usendtaylorx2l.lss.emc.com [10.243.10.188]) by mailsyshubprd06.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9NFYkac017239; Thu, 23 Oct 2014 11:34:46 -0400 Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043) id 07C705D734C; Thu, 23 Oct 2014 11:34:44 -0400 (EDT) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l.lss.emc.com (Postfix) with ESMTP id 72F445D7343; Thu, 23 Oct 2014 11:34:44 -0400 (EDT) To: Daniel Gutson cc: gdb Subject: Re: Breakpoint commands compiler In-reply-to: References: Comments: In-reply-to Daniel Gutson message dated "Fri, 17 Oct 2014 11:42:41 -0400." Date: Thu, 23 Oct 2014 15:35:00 -0000 Message-ID: <29700.1414078484@usendtaylorx2l> From: David Taylor X-RSA-Classifications: DLM_1, public X-Sentrion-Hostname: mailuogwprd03.lss.emc.com X-SW-Source: 2014-10/txt/msg00092.txt.bz2 1961+-07/28 To:"gdb@sourcewar possible gdb agent expression extension< wrote: > Hi, > > gdb is sometimes used for changing the runtime behavior of a program. > That is, suppose there is a program that has a bug, > it is spotted with gdb, then I create a set of non-stopping breakpoints that > "fix" the runtime behavior by altering memory and registers. > It does work, but it's slow. Agreed. Additionally speeding up the debug -- edit -- build -- download & boot cycle is a concern of ours. For us, while it only takes about 5 minutes to do a full build from scratch, the build -- download & boot part takes about 30 minutes. Some threads have timing constraints -- if the thread is left stopped waiting on the user to continue it, it will bring down the system. Other threads can wait an hour or more and it's no big deal. Depending on the problem being debugged, you might need additional time to get the system into the 'failing' state. So, the ability to 'patch' via debugger commands was desirable. Also, for unit testing it is nice to be able to artificially alter variables. > I was thinking to start a project to add a "breakpoint commands compiler" > to gdb, which basically generates C code from the breakpoint commands > (one function per breakpoint), > which in turns calls a C API (similar to the python api), invokes the compiler > (user-specified), loads it as a shared object, and finally replaces the commands > of the breakpoints by calls to the compiled breakpoint-functions. > > Any comment/suggestion? Would this be accepted within gdb? Another option would be, if the target supports it, to download the breakpoint commands to the target and have the target execute them. In the remote protocol the Z0 command takes an optional cond_list and an optional cmd_list. Back on July 28th I posted a message, subject 'possible gdb agent expression extension' that partially addresses this. Judging from the response, or should I say lack of response, no one seemed to care. The proposal addresses the setting variables part of the problem. We went ahead with it and it is about half done. The pieces remaining are primarily the gdbserver and testsuite changes. I keep getting pulled onto other tasks, but I'm *hoping* to finish it before the end of the year. It's only useful if you have a remote target and the target supports agent bytecode expressions. There are many things missing from agent bytecode expressions to make them as useful as I'd like. But, it's a start. The biggest missing one is the lack of 'continue'. But, for 'continue', there is a workaround -- put the expressions into the condition and use the comma operator: real-condition && ((variable1 = value1), (variable2 = value2), 0) [My other proposal on that same day -- possible 'info macro' extension -- elicited no responses.]