This is the mail archive of the
mailing list for the GDB project.
Re: Static tracepoints support
> From: Pedro Alves <firstname.lastname@example.org>
> 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.