This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Tracepoint enhancements
On Thursday 06 November 2008 17:38:38 Nicholas Mc Guire wrote:
>
> > Michael Snyder wrote:
> >
> > >> One possible change to consider is to merge tracepoint setting into
> > >> breakpoint setting. Among other benefits would be a single numbering
> > >> scheme for breakpoints and tracepoints, plus we will be able to share
> > >> some machinery and make things more consistent.
>
> we have implemented tp for gdb 6.3-6.6 and it might help to play with it
> before redesigning things - in our implementation we did not merge tp and
> breakpoints as it makes it quite complicated, i.e. breakpoints allow
> multiple breakpoints at the same address - for tp this makes little sense.
I don't see any fundamental problem here.
> the other issue is that you dont care about call overhead on breakpoints
> but you do on tracepoints so you probably dont want to have too much
> runtime searching going on for tp.
What "runtime searching" do you have in mind?
>
> ftp://dslab.lzu.edu.cn/pub/gdb_tracepoints
>
>
>
> > >
> > > Just my personal opinion, I would find that confusing.
>
> and it would make scripting complicated as well.
Why?
>
> > >
> > > It seems useful to maintain a fairly sharp distinction
> > > between breakpoints and tracepoints, since their behavior
> > > is entirely different from both the implementation and the
> > > user's point of view.
> > >
> > > But I would not plan to make a fuss about it...
> >
> > I think breakpoints and tracepoints have very lots of common.
> >
> > First of all, the logic of resolving location specification to addresses
> > is, conceptually the same. Right now, breakpoints in constructors and
> > template functions work. Tracepoints don't seem to, because the fail
> > to use the multi-location breakpoint mechanisms. Tracepoints don't have
> > conditions -- which is something we want to fix -- and handling of condition
> > is a bit tricky too. Breakpoints in shared libraries work just fine --
> > and tracepoints should work too -- but they don't use pending breakpoints
> > mechanisms.
> >
>
> one simple way of handling conditional stuff would be to put it into the
> bytecode - you would incure the overhead of calling the stub,
What do you mean by "calling the stub". I think tracepoints should work
entirely on target without any interaction with gdb.
> but that
> might actually be more convenient with respect to temporal distortion. The
> overhead of tracepoints is quite conciderable and thus conditional
> breakpoints (notably in multithreaded apps) need to be placed
> "synchronously" to not lead to excessive distortions (alteast our
> implementatoin showd a conciderable overhead - but you might find a way to
> do better).
What do you mean by "synchronously". Note that gdb now can keep breakpoints
inserted in the target at all times, so the insertion/removal overhead can
be eliminated this way.
> > On the interface (MI) level breakpoints and tracepoints are essentially
> > the same. Breakpoints allow user, or frontend, to do something at specific
> > points of program. That something very well can be printing variables. In
> > fact, KDevelop does have "tracing" functionality for breakpoints -- where
> > on breakpoint hit, selected variables are printed and execution resumes.
> > Tracepoints are exactly the same, except that:
> >
> > - they are more efficient
>
> they are actually less efficient on the stub-side as they need to use
> bytecode to get hold of compound statements and that is definitly less
> efficient on the target than on the host.
Ok, "they are more efficient provided expression is small enough". For small
expressions, roundtrip to target will take more time than on-target evaluation.
> Aside from the current spec
> having a few sub-optimal things in it (like static array of registers)
>
> > - they don't cause frontend to be involved, because to be efficient,
> > they are entirely stub-side
>
> the mechanism is a bit different as you need to handle dynamic memmory
> allocation for tp or you would end up with a large blob preallocated - not
> an issue for breakpoints.
Are you talking about stub side of things. Yes, it's different, but for frontend,
it does not matter much how stub implements them.
> > So it makes perfect sense to treat tracepoints as specially-optimized versions
> > of breakpoints.
>
> I doubt that - de-facto the code would not share much - atleast in our
> implementation this was the case, and I doubt that maintenance wise it
> makes any sense to merge the code - notably I would expect that the tp
> code would start changing once it goes in mainline and users start playing
> with it.
I disagree. Experience will tell, I think.
- Volodya