This is the mail archive of the
mailing list for the GDB project.
Re: gdbserver tracepoint support (from Project Ideas page)
On Wed, 2008-02-20 at 17:35 -0800, Doug Evans wrote:
> On Wed, Feb 20, 2008 at 5:06 PM, Michael Snyder <firstname.lastname@example.org> 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?