From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4315 invoked by alias); 4 Jan 2011 12:07:24 -0000 Received: (qmail 4301 invoked by uid 22791); 4 Jan 2011 12:07:23 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 04 Jan 2011 12:07:18 +0000 Received: by wwi17 with SMTP id 17so14037501wwi.12 for ; Tue, 04 Jan 2011 04:07:15 -0800 (PST) Received: by 10.216.172.212 with SMTP id t62mr21359890wel.60.1294142835531; Tue, 04 Jan 2011 04:07:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.182.206 with HTTP; Tue, 4 Jan 2011 04:06:55 -0800 (PST) In-Reply-To: References: From: Hui Zhu Date: Tue, 04 Jan 2011 12:07:00 -0000 Message-ID: Subject: Re: [PATCH] tracepoint: add new trace command "printf"[0] gdb To: Doug Evans Cc: gdb-patches Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-01/txt/msg00059.txt.bz2 On Tue, Jan 4, 2011 at 14:18, Doug Evans wrote: > On Mon, Jan 3, 2011 at 8:33 PM, Hui Zhu wrote: >> On Tue, Jan 4, 2011 at 03:21, Doug Evans wrote: >>> On Mon, Jan 3, 2011 at 8:29 AM, Hui Zhu 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. =A0But 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. =A0It >>>> 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. =A0Sometimes, >> 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. =A0And sometime, it will disconnect. >> But if through tracepoint, I will not have this trouble. =A0I can "set >> disconnected-tracing on" to handle the network disconnect issue. =A0I >> still need to get the value from inferior through tfind and other >> commands. =A0It is still be affect by the low speed network. =A0So I make >> the tracepoint "printf" to handle it. >> >> 2. =A0KGTP(https://code.google.com/p/kgtp/) just support the gdb >> tracepoint rsp commands. =A0For not stop the Linux the Kernel. =A0It >> 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, =A0we >> can dump the gdbrsp package to a file and send to Kernel. =A0Then kernel >> can be debug without a local gdb or a remote connect. =A0 But user still >> need copy the trace file to pc that have GDB. =A0But 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. =A0I'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). =A0[If I'm wrong and agent exprs are used for other > things, great, we're already down this path.] =A0Are they useful for > more things? =A0[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 trace= points. > 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. =A0Tracepoints to me convey a specific > use-case and I'm not sure we should muddy that up. =A0But 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). =A0This is not an approval though. =A0 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. =A0Someone else is > free to review and approve it of course.] > That is great. Thanks Doug., Best, Hui