From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9232 invoked by alias); 28 Jun 2010 20:03:00 -0000 Received: (qmail 9118 invoked by uid 22791); 28 Jun 2010 20:02:58 -0000 X-SWARE-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout21.012.net.il (HELO mtaout21.012.net.il) (80.179.55.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 28 Jun 2010 20:02:51 +0000 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0L4Q00700QB83000@a-mtaout21.012.net.il> for gdb-patches@sourceware.org; Mon, 28 Jun 2010 23:02:48 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.126.255.236]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L4Q0077GQCN3200@a-mtaout21.012.net.il>; Mon, 28 Jun 2010 23:02:48 +0300 (IDT) Date: Mon, 28 Jun 2010 20:03:00 -0000 From: Eli Zaretskii Subject: Re: Static tracepoints support In-reply-to: <201006281326.39820.pedro@codesourcery.com> To: Pedro Alves Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83iq52c49n.fsf@gnu.org> References: <201006251931.57860.pedro@codesourcery.com> <83tyoqcc8i.fsf@gnu.org> <201006281326.39820.pedro@codesourcery.com> 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: 2010-06/txt/msg00657.txt.bz2 > From: Pedro Alves > Date: Mon, 28 Jun 2010 13:26:38 +0100 > > > Thanks. However, does it mean we will only support LTTng/UST on > > remote targets, not natively? > > Yes. The whole tracepoint support in GDB only works on remote targets > presently. > > > If so, what would it take to add native > > support as well? > > You'd need to make the general tracing infrastruture work > work on native targets first somehow. Too bad. I guess I'll have to wait on for this to happen. > > > (gdb) info static-tracepoint-markers > > > Enb Address What > > > n 0x00007ffff7996692 > > > String ID: metadata/core_marker_format > > > Extra: channel %s name %s format %s > > > > I'd suggest to have Address before Enb. > > Any particular reason? Enb is a minor attribute, it surprised me to see it the first in the line. > This is the same order of "info breakpoints" output. Ah, but "info breakpoints" starts with a number, which is a kind of ID of the breakpoint. There's nothing like that here, but the address can serve as replacement. Not a major issue, obviously. > It leaves Address and What alongside, wich IMO is better as they're ralated. We could put Enb last. > > > The "What" column is similar to the "info breakpoints" output, and > > > shows the source location of the marker, if possible. > > > > Why wouldn't it be possible? Why some of the entries above don't have > > this data? > > If you have no debug info for the locations, the "What" field is empty, > just like with "info breakpoints": Well, maybe it's worth mentioning. > I can make that an alias if you'd like. I tend to just use , and > so I don't see a problem here. That was just for consistency with shorter names in the table, to make it align. If we leave the table in its original form, there's no reason to change the command name; I agree that completion solves the issue with long names, if there is such an issue. > Multiple breakpoints at one place are permitted, and useful if conditional. > > I don't think it is incomplete; it sounds correct to me. A breakpoint can > be conditional or unconditional, so I read that as: it's useful to have more > than one breakpoint at the same place when they are conditional breakpoints. But only if the conditionals are different. Anyway, it confused me, so perhaps it's a good idea to clarify. > > > +@cindex set static tracepoint > > > > This index entry would be much more efficient if it did not start with > > "set". For example, > > > > @cindex static tracepoint, setting > > Agreed. I see the same could be done to set fast tracepoint. I'll > see about auditing that and others after this patch is in. Thanks. > > > This usually consists of data formatted to a > > > +character string using the format provided by the programmer that > > > +instrumented the program. E.g., on some systems, an instrumentation > > > +point resembles a printf function call: > > > + > > > +@smallexample > > > + TRACE(tp1, "hello %s", master_name) > > > +@end smallexample > > > > How do you mean ``on some systems''? This support is inherently > > platform-specific, and is extremely unlikely to be extended to > > any platform but GNU/Linux. It doesn't seem a good idea to be vague > > about this issue here. > > This was trying to not be platform specific on purpose. The support in > GDB is not platform specific in any way. The gdbserver > implementation only works on linux GNU/Linux presently, but it could > be made to work on other platforms. UST runs entirely in userspace, > so it could be made to work on other systems as well. Maybe we should just say "on GNU/Linux", then. > New version attached. Okay? Yes. A few more nits: > +Markers}. For example, in the following small program using the UST > +tracing engine: > + > +@smallexample > +main () > +@{ > + trace_mark(ust, bar33, "str %s", "FOOBAZ"); > +@} > +@end smallexample > + > +The marker id is composed of joining the first two arguments to the I think you meant to begin with lower-case "the marker id", and you also want @noindent before it. > +@samp{hello $yourname}. When analying the trace buffer, you can ^^^^^^^^ A typo. > +@item E @var{nn} > +An error occurred. @var{nn} are hex digits. But in the code, I see error strings that use text, not hex digits. For example: > + sprintf (packet, "E.no marker found at 0x%s", paddress (address)); Thanks.