This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Fast tracepoints
- From: Tom Tromey <tromey at redhat dot com>
- To: Stan Shebs <stan at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 05 Jan 2010 15:43:28 -0700
- Subject: Re: [PATCH] Fast tracepoints
- References: <4B42A628.5060302@codesourcery.com>
- Reply-to: tromey at redhat dot com
>>>>> "Stan" == Stan Shebs <stan@codesourcery.com> writes:
Stan> This patch adds "fast" tracepoints to GDB.
Neat.
Stan> Most of the interesting trickery is on the target side - but don't
Stan> despair, Pedro has upcoming patches for a free version using gdbserver
Stan> and a special library.
I wonder whether this could somehow work with systemtap probe points.
Stan> + static void
Stan> + check_fast_tracepoint_sals (struct symtabs_and_lines *sals)
[...]
Stan> + if (!gdbarch_fast_tracepoint_valid_at (get_current_arch (),
Stan> + sal->pc, NULL))
Stan> + error (_("May not have a fast tracepoint at 0x%s"),
Stan> + paddress (get_current_arch (), sal->pc));
Stan> + static int
Stan> + i386_fast_tracepoint_valid_at (struct gdbarch *gdbarch,
Stan> + CORE_ADDR addr, int *isize)
[...]
Stan> + printf_filtered (_("Instruction at 0x%s is only %d bytes long, need at least %d bytes for the fast tracepoint jump\n"),
Stan> + paddress (gdbarch, addr), len, jumplen);
It seems like it would be nicer for the user if the _at method returned
a reason, so that it could be printed as "May not have a fast
tracepoint: ... : reason".
Similarly, it seems a little strange to me that a predicate function is
expected to print a warning.
Tom