public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: qiyaoltc@gmail.com (Yao Qi)
Cc: cole945@gmail.com (Wei-cheng Wang), qiyaoltc@gmail.com (Yao Qi),
	       gdb-patches@sourceware.org
Subject: Re: [PATCH 1/2 v2] Re-check fastpoint after reloading symbols.
Date: Tue, 15 Sep 2015 16:22:00 -0000	[thread overview]
Message-ID: <20150915162152.75FF92209@oc7340732750.ibm.com> (raw)
In-Reply-To: <86y4g93th7.fsf@gmail.com> from "Yao Qi" at Sep 14, 2015 04:34:28 PM

Yao Qi wrote:
> "Ulrich Weigand" <uweigand@de.ibm.com> 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
available there?

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

Bye,
Ulrich

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

  reply	other threads:[~2015-09-15 16:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-01 18:25 Wei-cheng Wang
2015-09-02 15:51 ` Yao Qi
     [not found]   ` <CAPmZyH61j2ECFu7vcg6ZAyhJWNGHpUHk60fOfkXG5qb9M-5pFA@mail.gmail.com>
2015-09-12 18:01     ` Wei-cheng Wang
2015-09-14 12:20       ` Ulrich Weigand
2015-09-14 15:34         ` Yao Qi
2015-09-15 16:22           ` Ulrich Weigand [this message]
2015-09-16  8:35             ` Yao Qi
2015-09-16 12:41               ` Ulrich Weigand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150915162152.75FF92209@oc7340732750.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=cole945@gmail.com \
    --cc=gdb-patches@sourceware.org \
    --cc=qiyaoltc@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).