From: Stan Shebs <stanshebs@earthlink.net>
To: tromey@redhat.com
Cc: Stan Shebs <stan@codesourcery.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] Fast tracepoints
Date: Wed, 06 Jan 2010 00:55:00 -0000 [thread overview]
Message-ID: <4B43DF5F.9060007@earthlink.net> (raw)
In-Reply-To: <m33a2k8967.fsf@fleche.redhat.com>
Tom Tromey wrote:
>>>>>> "Stan" == Stan Shebs <stan@codesourcery.com> writes:
>>>>>>
>
> Stan> This patch adds "fast" tracepoints to GDB.
>
> Neat.
>
> Stan> Most of the interesting trickery is on the target side - but don't
> Stan> despair, Pedro has upcoming patches for a free version using gdbserver
> Stan> and a special library.
>
> I wonder whether this could somehow work with systemtap probe points.
>
One of our other projects is to do "static tracepoints" that originate
outside GDB, and one of the side effects of the upcoming disconnected
tracing patch is that it introduces the idea of keeping the tracepoint
definition in the target. So it seems like a useful convergence to have
a tool-independent notion of a probe/tracepoint that can be used in
different contexts.
> It seems like it would be nicer for the user if the _at method returned
> a reason, so that it could be printed as "May not have a fast
> tracepoint: ... : reason".
>
Yeah, I considered it. It seemed like a localization mess to be
constructing strings from strings, plus I find it distasteful to have
the callee decide to allocate space in a way that compels the caller to
think about what to do with it. But as you observe, predicates doing
printouts isn't great either.
Stan
next prev parent reply other threads:[~2010-01-06 0:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-05 2:38 Stan Shebs
2010-01-05 20:07 ` Eli Zaretskii
2010-01-05 22:43 ` Tom Tromey
2010-01-06 0:55 ` Stan Shebs [this message]
2010-01-06 9:39 ` Mark Wielaard
2010-01-06 23:09 ` Tom Tromey
2010-01-06 23:41 ` Stan Shebs
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=4B43DF5F.9060007@earthlink.net \
--to=stanshebs@earthlink.net \
--cc=gdb-patches@sourceware.org \
--cc=stan@codesourcery.com \
--cc=tromey@redhat.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