* Tracepoints on gdb/gdbserver
@ 2003-09-30 12:50 Ramana Radhakrishnan
2003-09-30 13:06 ` Daniel Jacobowitz
0 siblings, 1 reply; 6+ messages in thread
From: Ramana Radhakrishnan @ 2003-09-30 12:50 UTC (permalink / raw)
To: gdb; +Cc: jimb, ac131313, drow
hi all,
This is regarding tracepoints on gdb/ gdbserver. What we are
trying to do is to implement tracepoints in gdbserver so that we could
have some sort of remote tracepointing. We are at a stage right now
where we are ready to take the plunge into actually implementing
tracepoints on gdbserver. What we have ready right now are just stubs
that take care of the protocol communication between gdb/tracepoint.c
and gdbserver/server.c . The following is a list of ideas / issues that
we have come up with.
* We were thinking of piggybacking the tracepoint support with
breakpoints in gdbserver , add a flag indicating that it would be a
tracepoint to reuse the code that the software breakpoint now uses in
gdbserver. As we see it there is not too much of a difference between
tracepoints and breakpoints other than the actions performed on a
{break/trace}point hit. By doing this the tracepoint implementation
could piggy back on the breakpoint support and this could also give rise
to per thread tracepoints in a mechanism similar to per thread
breakpoints.
* Another specification according to the info pages seems to be that
about the fact that all queries to the stub regarding memory / register
information should be answered by the stub from the current snapshot of
a tracepoint.
* Changes to be made in memory request handler , the handler for the
m<address>,<numbytes> packet in gdbserver/server.c to take care of
memory requests of transparent regions.
* Agent Expressions Interpreter integration with gdbserver. The
interpreter to take care of actions to be performed / the actual data to
be collected for every tracepoint.
* Collect Locals issue : with gdb snapshot dated 20030821 we are unable
to take care of collect $locals and collect $args .This gives an error
in gdb "Dont know how to trace local symbol ". This seems to be the
error value and it looks like support for the Address Class of a symbol
(LOC_COMPUTED) is not being taken care of right now.
regards
Ramana Radhakrishnan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Tracepoints on gdb/gdbserver
2003-09-30 12:50 Tracepoints on gdb/gdbserver Ramana Radhakrishnan
@ 2003-09-30 13:06 ` Daniel Jacobowitz
2003-09-30 14:00 ` Ramana Radhakrishnan
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Daniel Jacobowitz @ 2003-09-30 13:06 UTC (permalink / raw)
To: ramana; +Cc: gdb, jimb, ac131313
On Tue, Sep 30, 2003 at 05:46:54PM +0530, Ramana Radhakrishnan wrote:
> hi all,
> This is regarding tracepoints on gdb/ gdbserver. What we are
Great!
> trying to do is to implement tracepoints in gdbserver so that we could
> have some sort of remote tracepointing. We are at a stage right now
> where we are ready to take the plunge into actually implementing
> tracepoints on gdbserver. What we have ready right now are just stubs
> that take care of the protocol communication between gdb/tracepoint.c
> and gdbserver/server.c . The following is a list of ideas / issues that
> we have come up with.
>
>
> * We were thinking of piggybacking the tracepoint support with
> breakpoints in gdbserver , add a flag indicating that it would be a
> tracepoint to reuse the code that the software breakpoint now uses in
> gdbserver. As we see it there is not too much of a difference between
> tracepoints and breakpoints other than the actions performed on a
> {break/trace}point hit. By doing this the tracepoint implementation
> could piggy back on the breakpoint support and this could also give rise
> to per thread tracepoints in a mechanism similar to per thread
> breakpoints.
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.
> * Another specification according to the info pages seems to be that
> about the fact that all queries to the stub regarding memory / register
> information should be answered by the stub from the current snapshot of
> a tracepoint.
>
> * Changes to be made in memory request handler , the handler for the
> m<address>,<numbytes> packet in gdbserver/server.c to take care of
> memory requests of transparent regions.
>
> * Agent Expressions Interpreter integration with gdbserver. The
> interpreter to take care of actions to be performed / the actual data to
> be collected for every tracepoint.
>
> * Collect Locals issue : with gdb snapshot dated 20030821 we are unable
> to take care of collect $locals and collect $args .This gives an error
> in gdb "Dont know how to trace local symbol ". This seems to be the
> error value and it looks like support for the Address Class of a symbol
> (LOC_COMPUTED) is not being taken care of right now.
That's right. If someone implements the remainder of tracepoint
support I'll go back to looking at LOC_COMPUTED.
Do you have FSF copyright paperwork on file? If not, please do so.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Tracepoints on gdb/gdbserver
2003-09-30 13:06 ` Daniel Jacobowitz
@ 2003-09-30 14:00 ` Ramana Radhakrishnan
[not found] ` <vt2u16tnbjr.fsf@zenia.home>
2003-10-01 10:59 ` Tracepoints with shared lib. support Ramana Radhakrishnan
2 siblings, 0 replies; 6+ messages in thread
From: Ramana Radhakrishnan @ 2003-09-30 14:00 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb, jimb, ac131313
hi,
> Do you have FSF copyright paperwork on file? If not, please do so.
We are working on the paperwork. I am yet to receive the copyright form
in the mail . Its due in sometime this week. Would the copyright form be
necessary before all patches into gdb / gdbserver would be accepted ?
cheers
Ramana
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Tracepoints on gdb/gdbserver
[not found] ` <vt2u16tnbjr.fsf@zenia.home>
@ 2003-10-01 4:44 ` Ramana Radhakrishnan
0 siblings, 0 replies; 6+ messages in thread
From: Ramana Radhakrishnan @ 2003-10-01 4:44 UTC (permalink / raw)
To: Jim Blandy; +Cc: Daniel Jacobowitz, ramana, gdb, ac131313, mark.newman
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Tracepoints with shared lib. support.
2003-09-30 13:06 ` Daniel Jacobowitz
2003-09-30 14:00 ` Ramana Radhakrishnan
[not found] ` <vt2u16tnbjr.fsf@zenia.home>
@ 2003-10-01 10:59 ` Ramana Radhakrishnan
2003-10-01 14:48 ` Daniel Jacobowitz
2 siblings, 1 reply; 6+ messages in thread
From: Ramana Radhakrishnan @ 2003-10-01 10:59 UTC (permalink / raw)
To: Daniel Jacobowitz
Cc: gdb, jimb, ac131313, saurabh.verma, ankit.thukral, mark.newman
hi all,
Another query i had was regarding tracepoints on shared library
symbols. That would also have to be handled in a manner similar to the
way in which the breakpoints for shared libraries have been implemented.
I wonder if we need internal breakpoints on the shared library event
handling which would then take care of mapping the addresses to the
actual addresses because with the current status of tracepoints the
addresses do not get mapped to the actual addresses. So if we had a
tracepoint on a function in a shared library would we then not be
increasing the number of halts in the actual execution of the program.
regards
Ramana
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Tracepoints with shared lib. support.
2003-10-01 10:59 ` Tracepoints with shared lib. support Ramana Radhakrishnan
@ 2003-10-01 14:48 ` Daniel Jacobowitz
0 siblings, 0 replies; 6+ messages in thread
From: Daniel Jacobowitz @ 2003-10-01 14:48 UTC (permalink / raw)
To: ramana; +Cc: gdb, jimb, ac131313, saurabh.verma, ankit.thukral, mark.newman
On Wed, Oct 01, 2003 at 04:30:23PM +0530, Ramana Radhakrishnan wrote:
> hi all,
>
> Another query i had was regarding tracepoints on shared library
> symbols. That would also have to be handled in a manner similar to the
> way in which the breakpoints for shared libraries have been implemented.
> I wonder if we need internal breakpoints on the shared library event
> handling which would then take care of mapping the addresses to the
> actual addresses because with the current status of tracepoints the
> addresses do not get mapped to the actual addresses. So if we had a
> tracepoint on a function in a shared library would we then not be
> increasing the number of halts in the actual execution of the program.
Well, tracepoints haven't been made to work with shared libraries yet,
that's true. But it should be possible to enable/disable/move them at
the same time as breakpoints. There are always stops when loading a
shared library, and you'll have a whole lot of work cut out for you if
you want to change that. So the tracepoints don't increase the number
of halts.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-10-01 14:48 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-09-30 12:50 Tracepoints on gdb/gdbserver Ramana Radhakrishnan
2003-09-30 13:06 ` Daniel Jacobowitz
2003-09-30 14:00 ` Ramana Radhakrishnan
[not found] ` <vt2u16tnbjr.fsf@zenia.home>
2003-10-01 4:44 ` Ramana Radhakrishnan
2003-10-01 10:59 ` Tracepoints with shared lib. support Ramana Radhakrishnan
2003-10-01 14:48 ` Daniel Jacobowitz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox