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

[Hui Zhu <teawater at gmail dot com>]

On Thu, Jan 6, 2011 at 14:43, Hui Zhu <teawater@gmail.com> wrote:
> 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
>

Update follow the trunk.

Thanks,
Hui

2011-01-28  Hui Zhu  <teawater@gmail.com>

	* ax-gdb.c (gen_printf_expr_callback): New function.
	* ax-general.c (ax_memcpy): New function.
	(aop_map): Add new entry for "printf".
	(ax_print): Handle "printf".
	(ax_reqs): Ditto.
	* ax.h (agent_op): Add aop_printf.
	(ax_memcpy): Forward declare.
	* printcmd.c (printf_callback): New typedef.
	(string_printf): New function from ui_printf.
	(ui_printf): Call string_printf.
	(printf_command): Remove static.
	* tracepoint.c (printf_command, gen_printf_expr_callback,
	printf_callback, string_printf): Forward declares.
	(validate_actionline, encode_actions_1): handle printf_command.

Attachment: tp_print.txt
Description: Text document