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

Doug Evans
2011-01-04T06:19:13Z

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.]