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

[Hui Zhu <teawater@gmail.com>]

On Thu, Jan 6, 2011 at 04:51, Stan Shebs <stan@codesourcery.com> wrote:
> 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
>
>

That will be great!  Thanks Stan.

Hui