gdbserver tracepoint support (from Project Ideas page)

gdbserver tracepoint support (from Project Ideas page)

[Doug Evans]

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

Re: gdbserver tracepoint support (from Project Ideas page)

[Michael Snyder]

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.

Re: gdbserver tracepoint support (from Project Ideas page)

[Doug Evans]

On Wed, Feb 20, 2008 at 4:00 PM, Michael Snyder <msnyder@specifix.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?

Re: gdbserver tracepoint support (from Project Ideas page)

[Michael Snyder]

On Wed, 2008-02-20 at 16:19 -0800, Doug Evans wrote:
> On Wed, Feb 20, 2008 at 4:00 PM, Michael Snyder <msnyder@specifix.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...

Re: gdbserver tracepoint support (from Project Ideas page)

[Daniel Jacobowitz]

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

Re: gdbserver tracepoint support (from Project Ideas page)

[Doug Evans]

On Wed, Feb 20, 2008 at 5:06 PM, Michael Snyder <msnyder@specifix.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...
>
>
>
>

Re: gdbserver tracepoint support (from Project Ideas page)

[Daniel Jacobowitz]

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

Re: gdbserver tracepoint support (from Project Ideas page)

[Michael Snyder]

On Wed, 2008-02-20 at 17:35 -0800, Doug Evans wrote:
> On Wed, Feb 20, 2008 at 5:06 PM, Michael Snyder <msnyder@specifix.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?

Re: gdbserver tracepoint support (from Project Ideas page)

[Doug Evans]

On Thu, Feb 21, 2008 at 11:45 AM, Michael Snyder <msnyder@specifix.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?