Re: Static tracepoints support

[Eli Zaretskii <eliz at gnu dot org>]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Mon, 28 Jun 2010 13:26:38 +0100
> 
> > > +/* When symbols change, it probably means the sources changed as well,
> > > +   and it might mean the static tracepoint markers are no longer at
> > > +   the same address or line numbers they used to be at last we
> > > +   checked.  Losing your static tracepoints whenever you rebuild is
> > > +   undesirable.  This function tries to resync/rematch gdb static
> > > +   tracepoints with the markers on the target.  The heuristic is:
> > > +
> > > +   1) look for a marker at the old PC.  If one is found there, assume
> > > +   to be the same marker.  If the name / string id of the marker found
> > > +   is different from the previous known name, assume that means the
> > > +   user renamed the marker in the sources, and output a warning.
> > > +
> > > +   2) If a marker is no longer found at the same address, it may mean
> > > +   the marker no longer exists.  But it may also just mean the code
> > > +   changed a bit.  Maybe the user added a few lines of code that made
> > > +   the marker move up or down (in line number terms).  Ask the target
> > > +   for info about the marker with the string id as we knew it.  If
> > > +   found, update line number and address in the matching static
> > > +   tracepoint.  */
> > 
> > I would suggest to reverse the order of the steps: first to query the
> > target about the marker with the old string ID, and only if it is not
> > found, use the heuristics in step 1.  The rationale is that if the
> > target can provide the info, it is always more reliable than any
> > heuristics.

You didn't respond to this part.  I'm curious to hear your opinion on
why it is TRT the way you coded it.