Re: [PATCH] tracepoint: add new trace command "printf"[0] gdb

[Stan Shebs <stan@codesourcery.com>]

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