gdbserver tracepoint support (from Project Ideas page)

Hi.  The wiki Project Ideas page has this for gdbserver:

    * Gdbserver doesn't support tracepoints. A few people
have said
they would work on this, but no patches for it have ever
been
submitted to the mailing list. This could be a nice
introductory
project for someone interested in remote debugging.

Can anyone give me an idea of what they think this involves,
and if
any work has been done on this since the wiki entry was
written?

TIA

On Wed, 2008-02-20 at 15:24 -0800, Doug Evans wrote:
> Hi.  The wiki Project Ideas page has this for
gdbserver:
> 
>     * Gdbserver doesn't support tracepoints. A few
people have said
> they would work on this, but no patches for it have
ever been
> submitted to the mailing list. This could be a nice
introductory
> project for someone interested in remote debugging.
> 
> Can anyone give me an idea of what they think this
involves, and if
> any work has been done on this since the wiki entry was
written?


What work it involves -- 
1) First gdbserver must understand the extra set of 
tracepoint remote protocol commands (or a subset of them:
tracepoint support is very subset-able).  I'm sure these
commands are documented somewhere...
2) Then gdbserver has to know how to implement a tracepoint,

ie. to stop the child, quickly collect a well defined set
of
data into a cache, then continue the child without any 
interaction with gdb.

AFAIK no one has worked on it in a while.

On Wed, Feb 20, 2008 at 4:00 PM, Michael Snyder
<msnyderspecifix.com> wrote:
>  > Can anyone give me an idea of what they think
this involves, and if
>  > any work has been done on this since the wiki
entry was written?
>
>
>  What work it involves --
>  1) First gdbserver must understand the extra set of
>  tracepoint remote protocol commands (or a subset of
them:
>  tracepoint support is very subset-able).  I'm sure
these
>  commands are documented somewhere...
>  2) Then gdbserver has to know how to implement a
tracepoint,
>  ie. to stop the child, quickly collect a well defined
set of
>  data into a cache, then continue the child without
any
>  interaction with gdb.
>
>  AFAIK no one has worked on it in a while.

Thanks.

Another question.  While there mightn't be much benefit to
implementing tracepoints natively as far speed of data
collection is
concerned, having a consistent u/i and capabilities native
vs remote
might be reasons to warrant a native implementation.  Anyone
have any
thoughts on a native implementation?

On Wed, 2008-02-20 at 16:19 -0800, Doug Evans wrote:
> On Wed, Feb 20, 2008 at 4:00 PM, Michael Snyder
<msnyderspecifix.com> wrote:
> >  > Can anyone give me an idea of what they
think this involves, and if
> >  > any work has been done on this since the
wiki entry was written?
> >
> >
> >  What work it involves --
> >  1) First gdbserver must understand the extra set
of
> >  tracepoint remote protocol commands (or a subset
of them:
> >  tracepoint support is very subset-able).  I'm
sure these
> >  commands are documented somewhere...
> >  2) Then gdbserver has to know how to implement a
tracepoint,
> >  ie. to stop the child, quickly collect a well
defined set of
> >  data into a cache, then continue the child
without any
> >  interaction with gdb.
> >
> >  AFAIK no one has worked on it in a while.
> 
> Thanks.
> 
> Another question.  While there mightn't be much benefit
to
> implementing tracepoints natively as far speed of data
collection is
> concerned, having a consistent u/i and capabilities
native vs remote
> might be reasons to warrant a native implementation. 
Anyone have any
> thoughts on a native implementation?

When you say "[not] much benefit to implementing
tracepoints 
natively", do you mean "as opposed to just using
gdbserver
or equivalent"?

I've given thought to the issue, and I think Jim Blandy has

as well.  Not enough thought to make a very complete
picture...

I think it would be useful, but then, I've always thought
tracepoints would find more use than they seem to have in
practice...

On Wed, Feb 20, 2008 at 05:06:29PM -0800, Michael Snyder
wrote:
> I think it would be useful, but then, I've always
thought
> tracepoints would find more use than they seem to have
in
> practice...

That's because they're never implemented on the targets
people want
them for   A native
implementation would be good to have.

Michael said about everything I can think of about the plan
of attack
for a gdbserver implementation.  The status hasn't changed
since the
wiki entry was added; yet another implementation has been
done
in gdbserver since then, and its author was interested in
contributing
it, but the legal paperwork was out of reach for his
employer :-(

-- 
Daniel Jacobowitz
CodeSourcery

On Wed, Feb 20, 2008 at 5:06 PM, Michael Snyder
<msnyderspecifix.com> wrote:
>  When you say "[not] much benefit to implementing
tracepoints
>  natively", do you mean "as opposed to just
using gdbserver
>  or equivalent"?

Not precisely.  To be honest I was hedging my bets because
I've kinda
thought tracepoints would find more use too, and given that
there
isn't yet support in gdbserver or native, I was wondering if
there was
a sufficient reason for not doing it that I was overlooking.
 Part of
the initial reason for implementing them was to avoid
transmitting
packets back and forth at each tracepoint.  That reason
doesn't really
apply to a native implementation but the process switching
to
implement this in ptrace (for linux) is a non-trivial
intrusion for
many apps (as it will be in gdbserver too), so maybe that's
why it
hasn't been implemented.  A hybrid approach would be way
cool (i.e.
instrumenting the target program so tracepoints didn't stop
the
program even when running natively - this is where remote
targets have
an advantage, the stub is already in the same address space
and
process - but that ups the complexity a wee bit).

> I've given thought to the issue, and I think Jim Blandy
has
>  as well.  Not enough thought to make a very complete
picture...
>
>  I think it would be useful, but then, I've always
thought
>  tracepoints would find more use than they seem to have
in
>  practice...
>
>
>
>

On Wed, Feb 20, 2008 at 05:35:58PM -0800, Doug Evans wrote:
> hasn't been implemented.  A hybrid approach would be
way cool (i.e.
> instrumenting the target program so tracepoints didn't
stop the
> program even when running natively - this is where
remote targets have
> an advantage, the stub is already in the same address
space and
> process - but that ups the complexity a wee bit).

Hmm, uprobes + SystemTap...

-- 
Daniel Jacobowitz
CodeSourcery

On Wed, 2008-02-20 at 17:35 -0800, Doug Evans wrote:
> On Wed, Feb 20, 2008 at 5:06 PM, Michael Snyder
<msnyderspecifix.com> wrote:
> >  When you say "[not] much benefit to
implementing tracepoints
> >  natively", do you mean "as opposed to
just using gdbserver
> >  or equivalent"?
> 
> Not precisely.  To be honest I was hedging my bets
because I've kinda
> thought tracepoints would find more use too, and given
that there
> isn't yet support in gdbserver or native, I was
wondering if there was
> a sufficient reason for not doing it that I was
overlooking.  Part of
> the initial reason for implementing them was to avoid
transmitting
> packets back and forth at each tracepoint.  That reason
doesn't really
> apply to a native implementation but the process
switching to
> implement this in ptrace (for linux) is a non-trivial
intrusion for
> many apps (as it will be in gdbserver too), so maybe
that's why it
> hasn't been implemented.  A hybrid approach would be
way cool (i.e.
> instrumenting the target program so tracepoints didn't
stop the
> program even when running natively - this is where
remote targets have
> an advantage, the stub is already in the same address
space and
> process - but that ups the complexity a wee bit).

I've always thought that one interesting implementation for
tracepoint data collection would be as a shared library
that
the child program could be linked with at runtime -- in the
manner of libsegfault, so that you don't have to change the
child program at all.  In that way, it would share address
space and only incur the cost of a signal handler, not a
full context switch (or even a thread context switch).

Is that something like your thinking?

On Thu, Feb 21, 2008 at 11:45 AM, Michael Snyder
<msnyderspecifix.com> wrote:
>  > A hybrid approach would be way cool (i.e.
>  > instrumenting the target program so tracepoints
didn't stop the
>  > program even when running natively - this is
where remote targets have
>  > an advantage, the stub is already in the same
address space and
>  > process - but that ups the complexity a wee
bit).
>
>  I've always thought that one interesting
implementation for
>  tracepoint data collection would be as a shared
library that
>  the child program could be linked with at runtime --
in the
>  manner of libsegfault, so that you don't have to
change the
>  child program at all.  In that way, it would share
address
>  space and only incur the cost of a signal handler, not
a
>  full context switch (or even a thread context
switch).
>
>  Is that something like your thinking?

That is one way to implement it, my "way cool"
comment had in mind a
more efficient implementation (albeit more complex too).  I
don't have
any numbers so I'm not advocating one over the other.

btw, is there any existing implementation anywhere for a
remote
target?  Something in libgloss or rda (redhat debug agent?)
or some
such?