Re: [PATCH 1/2 v2] Re-check fastpoint after reloading symbols.

["Ulrich Weigand" <uweigand@de.ibm.com>]

Yao Qi wrote:
> "Ulrich Weigand" <uweigand@de.ibm.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
target_get_min_fast_tracepoint_insn_len callback.

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.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com