Re: Static tracepoints support

[Eli Zaretskii <eliz at gnu dot org>]

> From: Pedro Alves <pedro@codesourcery.com>
> 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 <tab>, 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.