Re: Tracepoint enhancements

[Nicholas Mc Guire <hofrat at hofr dot at>]

> 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.
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.


You might want to give it a look at:

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.

> >
> > 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, 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).


> 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. 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.

>
> 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.

> In order for breakpoint to be optimized like this, the list
> of commands for that breakpoints should only use a limited set of commands,
> and end with 'continue'
>
> > One more thing, only vaguely related...
> >
> > I've thought that if we had the ability to attach an expression
> > (in pcode such as we use for tracepoints) to a conditional breakpoint,
> > we could have the conditional evaluation be done on the target
> > rather than by gdb, which would be a big performance win for
> > conditional breakpoints or watchpoints.
>
> Yes. We want conditional tracepoints, and the condition would have to be evaluated
> on the target. And if breakpoints and tracepoints are unified, both breakpoints and
> tracepoints will benefit.
>

I dont see any benefit for the breakpoints by merging in tracepoints.

hofrat