From: Doug Evans <dje@google.com>
To: Hui Zhu <teawater@gmail.com>
Cc: gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH] tracepoint: add new trace command "printf"[0] gdb
Date: Tue, 04 Jan 2011 06:19:00 -0000 [thread overview]
Message-ID: <AANLkTinOj2JE8U=cu1ntVfh7nmTwnKDTox22da09vfyF@mail.gmail.com> (raw)
In-Reply-To: <AANLkTiktJB=V0KS0u31rWMA6CyoV6J3+9Yufcgr=efr-@mail.gmail.com>
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.]
next prev parent reply other threads:[~2011-01-04 6:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-03 16:29 Hui Zhu
2011-01-03 19:21 ` Doug Evans
2011-01-04 4:34 ` Hui Zhu
2011-01-04 6:19 ` Doug Evans [this message]
2011-01-04 12:07 ` Hui Zhu
2011-01-05 17:24 ` Doug Evans
2011-01-05 18:18 ` Michael Snyder
2011-01-06 6:42 ` Hui Zhu
2011-01-05 20:51 ` Stan Shebs
2011-01-06 6:43 ` Hui Zhu
2011-01-28 5:54 ` Hui Zhu
2011-02-04 15:59 ` Hui Zhu
2011-02-11 3:49 ` Hui Zhu
2011-02-11 18:45 ` Tom Tromey
2011-02-17 8:16 ` Hui Zhu
2011-02-21 8:18 ` Hui Zhu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='AANLkTinOj2JE8U=cu1ntVfh7nmTwnKDTox22da09vfyF@mail.gmail.com' \
--to=dje@google.com \
--cc=gdb-patches@sourceware.org \
--cc=teawater@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).