This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH 1/2 v2] Re-check fastpoint after reloading symbols.
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: qiyaoltc at gmail dot com (Yao Qi)
- Cc: qiyaoltc at gmail dot com (Yao Qi), cole945 at gmail dot com (Wei-cheng Wang), gdb-patches at sourceware dot org
- Date: Wed, 16 Sep 2015 14:41:25 +0200 (CEST)
- Subject: Re: [PATCH 1/2 v2] Re-check fastpoint after reloading symbols.
- Authentication-results: sourceware.org; auth=none
Yao Qi wrote:
> "Ulrich Weigand" <email@example.com> writes:
> > I guess I'm not really sure what the difference is between checks
> > "using GDBserver internal knowledge" and those that don't. Doesn't
> > the x86 check, strictly speaking, also use GDBserver internal knowlegde,
> > i.e. it knows which instruction GDBserver attempts to place at the
> > tracepoint location, and therefore knows how much space must be
> > available there?
> It is different when GDB talks with some debugging stubs other than
> GDBserver, which support tracepoint too. It is OK that GDB checks fast
> tracepoint's validity according to GDB's own knowledge, such as
> instruction size. That is what x86 does nowadays. However, GDB can't
> check validity by checking whether it is too far to jump to the jumppad
> from the tracepoint address. Jumppad address is unknown to GDB, and
> other debugging stub may allocate jumppad differently. PPC GDB
> tracepoint do checks in this way, which isn't right to me.
I understand simply measuring how much space is *available* does not
require any GDBserver knowledge. But how much space is *required*
does depend on the agent implementation. However, what I missed is
that this fact is actually retrieved from the target using a special
So you're right that the current x86 implementation does not rely on
agent implentation details in GDB. I guess we could do something
similar for ppc64 by adding a new remote protocol command to verify
whether a tracepoint address is valid. (This could in fact supersede
the target_get_min_fast_tracepoint_insn_len callback then.)
But I guess I'd still prefer to do it this way, to avoid needing
two packet round trips for each tracepoint:
> > That's why I am now wondering whether the best fix shouldn't be to
> > simply remove the GDB-side check completely, even on x86, and solely
> > rely on GDBserver reporting errors via the remote protocol ...
> It is fine with me to move validity checks to GDBserver side, but we
> need to add some thing to decode x86 instructions and get to know
> instruction length. Nowadays, we are using gdb_print_insn which
> calls some function in opcodes in GDB side, but it doesn't exist
> in GDBserver side.
That's true, but this information is computed by GDB and passed to
the remote agent via the orig_size field of the tracepoint packet
anyway, see this piece of code in remote_download_tracepoint:
xsnprintf (buf + strlen (buf), BUF_SIZE - strlen (buf), ":F%x",
gdb_insn_length (loc->gdbarch, tpaddr));
So the remote agent doesn't actually need to compute it again.
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain