From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11978 invoked by alias); 4 Jan 2011 06:19:13 -0000 Received: (qmail 11968 invoked by uid 22791); 4 Jan 2011 06:19:11 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.67) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 04 Jan 2011 06:19:05 +0000 Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p046J1g3024449 for ; Mon, 3 Jan 2011 22:19:02 -0800 Received: from qyj19 (qyj19.prod.google.com [10.241.83.83]) by kpbe18.cbf.corp.google.com with ESMTP id p046Ix8h021530 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 3 Jan 2011 22:19:00 -0800 Received: by qyj19 with SMTP id 19so16665388qyj.19 for ; Mon, 03 Jan 2011 22:18:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.95.200 with SMTP id e8mr18551606qcn.213.1294121939483; Mon, 03 Jan 2011 22:18:59 -0800 (PST) Received: by 10.220.118.80 with HTTP; Mon, 3 Jan 2011 22:18:59 -0800 (PST) In-Reply-To: References: Date: Tue, 04 Jan 2011 06:19:00 -0000 Message-ID: Subject: Re: [PATCH] tracepoint: add new trace command "printf"[0] gdb From: Doug Evans To: Hui Zhu Cc: gdb-patches Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true 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/msg00054.txt.bz2 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. 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 tracepo= ints. 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.]