Re: Tracepoint enhancements

[Vladimir Prus <vladimir@codesourcery.com>]

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