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]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]