Some days ago, I sent a test case (trace-break.exp) and a fix about
setting breakpoint and fast tracepoint at the same the same address,

  [patch, gdbserver] Uninsert bpkt when regular and fast tracepoint are
set at the same address
  http://sourceware.org/ml/gdb-patches/2011-10/msg00714.html

I read trace-break.exp again, and find we didn't test setting two fast
tracepoints at the same address.  This test can be done easily by adding
one line in trace-brea.exp (see below in my patch), however, it reveals
one bug about tracepoint.

  FAIL: gdb.trace/trace-break.exp: 2 ftrace ftrace on: tfind frame 1
  FAIL: gdb.trace/trace-break.exp: 2 ftrace ftrace off: tfind frame 1

The problem is that when setting two fast tracepoints at the same place,
only one works.  When setting fast tracepoint at an address, a jump pad
is created to connect a jmp insn written at tracepoint place and
collection routine.  Even multiple fast tracepoints are set at the same
address, there is only jump pad associated with this address.  Inferior
will jump to gdb_collect from jump pad with the first tracepoint
information, rather than all tracepoints information at that address.
This is cause of this problem.

Fortunately, tracepoints list are sorted, and jump pad is associated
with the "first" tracepoint of them.  So tracepoint passed to
gdb_collect is the "first" tracepoint of them which have the same
address, then we can loop over tracepoints started from "first"
tracepoint, and call collect_data_at_tracepoint in the loop.  This is
how this written.  Tested on x86_64-linux native-gdbserver, OK to apply?

-- 
Yao (齐尧)