This is the mail archive of the
mailing list for the GDB project.
[patch 0/5] pending tracepoint
- From: Yao Qi <yao at codesourcery dot com>
- To: "gdb-patches at sourceware dot org ml" <gdb-patches at sourceware dot org>
- Date: Tue, 15 Nov 2011 15:01:02 +0800
- Subject: [patch 0/5] pending tracepoint
Hi, `pending tracepoint' is quite similar to `pending breakpoint', that
is, tracepoint locations are unknown at first, so they are `pending'
there. Once locations are resolved, they are downloaded to inferior and
As this patch set below goes into trunk, it becomes relatively
straightforward to support pending tracepoint.
[patch 0/8] Download tracepoint locations when tracing is running
GDB has to allow to create `pending tracepoint', just similar to
creating pending breakpoint. GDB has to take care of validation of
pending fast tracepoint. This is done by patch 2/5.
Although tracepoint works with GDB disconnected, resolution to `pending
tracepoint' need GDB connected, so GDB will emit a warning when
disconnect from remote stub while there are still some pending
tracepoints. This is done by patch 3/5. Patch 4/5 and 5/5 are about
test cases and documentation changes respectively.
Regression tested on x86_64-linux.
Once this patch set goes into trunk, `pending tracepoint' work is done,
but there is still one extended work, "validate pending fast tracepoint
when it is resolved". It can be divided into two parts,
1) validate fast tracepoint on location level, and keep acceptable
locations. What we are doing now is that validate each location of a
tracepoint, if one of locations doesn't meet requirements, the
tracepoint can't be created. It is a little too conservative. We can
change this model to "create location for tracepoint if it meets
requirements". This is not about `pending tracepoint' at all.
2) validate fast tracepoint locations when they are resolved, only
adding locations meet requirements into tracepoint.
I'll send patches out this week.