From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32160 invoked by alias); 5 Jan 2011 20:51:49 -0000 Received: (qmail 32148 invoked by uid 22791); 5 Jan 2011 20:51:48 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 05 Jan 2011 20:51:44 +0000 Received: (qmail 26654 invoked from network); 5 Jan 2011 20:51:42 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Jan 2011 20:51:42 -0000 Message-ID: <4D24D9DD.8090104@codesourcery.com> Date: Wed, 05 Jan 2011 20:51:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [PATCH] tracepoint: add new trace command "printf"[0] gdb References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2011-01/txt/msg00086.txt.bz2 On 1/3/11 10:18 PM, Doug Evans wrote: > [for reference sake] > To me this is a subset of a bigger feature set that is missing: > partitioning of the things that can be accomplished by gdbserver from > the setup that is needed (IOW separate the heavy lifting of parsing > debug info and translating a user query into, for example, an agent > expression (the gdb side) from the processing of that query when the > breakpoint(/tracepoint) is hit (the gdbserver side). > Plus it might be useful to not require a gdb/gdbserver connection to > get things started, e.g., convey the tracepoint info (and anything > else) to gdbserver from a local source. > [I'm using "query" loosely here. I'm using "gdbserver" loosely too: > anything that looks like gdbserver to gdb will do.] I'm actually working on a contract proposal to do a bunch of work in this area. One of the specific ideas is to introduce a "dynamic printf" that works somewhat like what I think Hui Zhu was wanting; it stops the program at a location, runs the printf in gdbserver, and then continues. Another one of the ideas is to use agent expressions to do target-side conditional breakpoints. This is especially compelling for many-core targets, where we don't want 100 threads on 100 cores to be trying to get GDB to do 100 conditional expression evaluations all at once. I didn't specifically propose to go beyond that, into general partitioning of command lists between host and target, although it's a very interesting direction. The idea gets me to thinking about whether we should keep the command list form, or raise it to the level of a real language, or maybe support several - Mentor's EDGE debugger for instance uses a C syntax for its "codelets" ( http://www.mentor.com/embedded-software/resources/overview/codelets-15b9eaed-8e4b-43a2-aad5-c189cd7f2d68 ) even though they run on the host, and whether the language is C or Python, it seems useful to be able to inject real code bits into the target system. Anyway, if we get the contract (fingers crossed!) then I expect we'll be putting up some proposals for discussion within the next couple of months. I'll comment on the patch in a different message. Stan