This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |