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

[Yao Qi <qiyaoltc at gmail dot com>]

"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.

>
> 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.

-- 
Yao (éå)