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

[Hui Zhu <teawater@gmail.com>]

On Tue, Jan 4, 2011 at 14:18, Doug Evans <dje@google.com> wrote:
> On Mon, Jan 3, 2011 at 8:33 PM, Hui Zhu <teawater@gmail.com> wrote:
>> On Tue, Jan 4, 2011 at 03:21, Doug Evans <dje@google.com> wrote:
>>> On Mon, Jan 3, 2011 at 8:29 AM, Hui Zhu <teawater@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I add a new patch add new trace command "printf".
>>>> This printf is same with the simple gdb command, it can do formatted
>>>> output.  But it will happen in gdbserver part when it break by a
>>>> tracepoint.
>>>> Then the user can get the format value that he want in tracepint.  It
>>>> will be more easy and clear to handle the bug sometimes.
>>>
>>> One could do this with a breakpoint and attaching commands to the
>>> breakpoint too, right?
>>> Or are they too cumbersome for the intended use case?
>>> [Extending tracepoints like this doesn't seem justified yet, so I'm
>>> just looking for more data.]
>>>
>>
>> Thanks Doug.
>>
>> I agree with the tracepoint "printf" will be very close with add a
>> breakpoint commands "printf" if the gdb and gdbserver in same pc.
>>
>> But I have some status need the tracepoint "printf" that breakpoint is
>> not very fit with.
>> 1. The gdb and gdbserver connect through a low speed net.  Sometimes,
>> the debug target that I use is in the other side of the earth.
>> The breakpoint commands "printf" is too slow for that issue, because
>> each time the inferior is break by the breakpoint, gdbserver need send
>> the rsp package to gdb, and gdb will get the data that "printf" need
>> though low speed net from gdbsever.  And sometime, it will disconnect.
>> But if through tracepoint, I will not have this trouble.  I can "set
>> disconnected-tracing on" to handle the network disconnect issue.  I
>> still need to get the value from inferior through tfind and other
>> commands.  It is still be affect by the low speed network.  So I make
>> the tracepoint "printf" to handle it.
>>
>> 2.  KGTP(https://code.google.com/p/kgtp/) just support the gdb
>> tracepoint rsp commands.  For not stop the Linux the Kernel.  It
>> doesn't support the breakpoint.
>> So if it want directly show the Kernel val value, it need "printf".
>> This printf will be very powerful that can set most part of Kernel and
>> we can set condition for it.
>> And in https://code.google.com/p/kgtp/wiki/HOWTO#Offline_debug,  we
>> can dump the gdbrsp package to a file and send to Kernel.  Then kernel
>> can be debug without a local gdb or a remote connect.   But user still
>> need copy the trace file to pc that have GDB.  But if support
>> tracepoint "printf", we will not need do that.
>
> Thanks for the additional info.
> I still think this is kinda orthogonal to tracepoint functionality,
> and thus implementing it on top of tracepoints is a hack, but I
> understand better why you want it.
>
> [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.]
>
> AIUI, agent expressions are currently only used for tracepoints (I
> thought they might be used for fast conditional breakpoints but I
> can't find it).  [If I'm wrong and agent exprs are used for other
> things, great, we're already down this path.]  Are they useful for
> more things?  [I don't know what, but if printf is useful, I can
> imagine there being more things that are useful too.]
> Thus it might be useful to take a step back before adding printf to tracepoints.
> E.g. Another way to go would be to have a new kind of command list
> that can be attached to breakpoints, commands that are executed on the
> gdbserver side.
>
> [One might think why not just add printf (and whatever else) to
> tracepoints and leave it at that.  Tracepoints to me convey a specific
> use-case and I'm not sure we should muddy that up.  But for now I
> suppose printf could be sufficiently useful, so I'm not opposed to the
> patch (pragmatic hacks are sometimes useful enough to justify their
> existence).  This is not an approval though.   I can see the patch
> needs at least a few changes, but before reviewing it I'd like to make
> sure there is general agreement on this approach.  Someone else is
> free to review and approve it of course.]
>

That is great.  Thanks Doug.,

Best,
Hui