This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Tracepoints on gdb/gdbserver
- From: Ramana Radhakrishnan <ramana dot radhakrishnan at codito dot com>
- To: Jim Blandy <jimb at redhat dot com>
- Cc: Daniel Jacobowitz <drow at mvista dot com>, ramana at codito dot com, gdb at sources dot redhat dot com, ac131313 at redhat dot com, mark dot newman at lmco dot com
- Date: 01 Oct 2003 10:17:29 +0530
- Subject: Re: Tracepoints on gdb/gdbserver
- Organization: Codito Technologies
- References: <1064924214.3808.157.camel@numenor.codito.co.in> <20030930125017.GA23342@nevyn.them.org> <vt2u16tnbjr.fsf@zenia.home>
- Reply-to: ramana at codito dot com
On Wed, 2003-10-01 at 04:12, Jim Blandy wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
> > That'll work. I got the impression that tracepoints are designed to be
> > even lighter-weight than that; you can implement them via an agent
> > expression -> native assembly conversion. But this requires runtime
> > patching and is quite complicated. Just saving the overhead of the
> > remote protocol will be useful.
>
> Yes. The original implementation used a bytecode interpreter (which
> is really pretty fast), but it was an embedded board with no OS, and
> the interpreter ran in the same address space as the program being
> debugged, so those memory references were just load instructions, and
> the trace opcodes were just memcpy calls.
>
> If you implement tracepoints in gdbserver, then those are going to
> become ptrace calls, which are going to be a lot slower. It might
> still be fast enough for your purposes --- but I just want to point
> out that it's not the same arrangement we used in the original
> application.
I agree that it would be slow but as Daniel points out, compared the
overhead of the remote protocol, it would still be useful.
regards
Ramana