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: cole945 at gmail dot com (Wei-cheng Wang), qiyaoltc at gmail dot com (Yao Qi), gdb-patches at sourceware dot org
- Date: Tue, 15 Sep 2015 18:21:52 +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" <firstname.lastname@example.org> writes:
> > What I had asked Wei-cheng to implement is to fix these two issues:
> > properly duplicate the validity check for PowerPC, and re-validate
> > every time locations are resolved.
> That is fine by me in general, and I attach a reproducer to trigger GDB
> internal error on x86. Wei-cheng's patch fixes this internal error, and
> instead, a normal error is emitted.
Thanks for the test case!
> > Maybe it would indeed be better to move the validity-checking logic
> > completely to the target side, i.e. always attempt to download the
> > tracepoint, and react more intelligently if that fails (e.g. downgrade
> > to a regular tracepoint?). I'm not sure if that is doable with the
> > current remote protocol definition. Thoughts?
> The duplicated checks in both GDB and GDBserver sides aren't that bad to
> me, however, I am worried about using internal knowledge of
> GDBserver and IPA to validate fast tracepoint in GDB side. I raised
> this here https://sourceware.org/ml/gdb-patches/2015-09/msg00041.html
> I suspect that we won't see GDB internal error on PPC if we don't do
> checks using GDBserver internal knowledge. Without GDBserver internal
> knowledge, ppc_fast_tracepoint_valid_at should always return true.
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
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 ...
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain