Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: "Tedeschi, Walfred" <walfred.tedeschi@intel.com>,
	qiyaoltc@gmail.com,        brobecker@adacore.com
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH V7] amd64-mpx: initialize bnd register before performing inferior calls.
Date: Wed, 08 Feb 2017 16:21:00 -0000	[thread overview]
Message-ID: <9851a15e-b03a-7e5b-8415-87260120df9a@redhat.com> (raw)
In-Reply-To: <88c7180f-8843-a148-425a-2adf56c6d0bf@redhat.com>

I just occurred to me that I think it's important that
we test what happens to the BND registers _after_ the
infcall finishes:

 #1 - by normal completion

 #2 - when it is interrupted midway, e.g., because the
      called function trips on a breakpoint.

I didn't find this in the current test.

I expect that in case #1, the BND registers are restored to
what they were before the infcall.  The test should exercise
this, by continuing execution after the infcall returns, and
checking that a bounds violation / lack of bounds violation,
is still detected / not detected as if the infcall didn't
happen.

Similarly, for #2, once gdb "silently stops" after being
resumed from the breakpoint hit, I think all registers are
restored, so the same testing would apply then.

You may also think about testing what should happen
to bounds checks done by the function that had the
breakpoint that interrupted the infcall, if you say, step
over some code inside that interrupted function.

Comprehensive testing like that would make it clearer how
the feature is meant to behave, and ensure it continues
working like that going forward.

Lastly, shouldn't the manual say something about all this?

Thanks,
Pedro Alves


  reply	other threads:[~2017-02-08 16:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-31 15:13 Walfred Tedeschi
2017-02-06 17:05 ` [ping] " Tedeschi, Walfred
2017-02-06 17:58 ` Pedro Alves
2017-02-07  8:56   ` Tedeschi, Walfred
2017-02-08 12:27     ` Pedro Alves
2017-02-08 16:21       ` Pedro Alves [this message]
2017-02-08 16:31         ` Tedeschi, Walfred
2017-02-13  8:33       ` Tedeschi, Walfred
     [not found]         ` <75843d02-1b8b-f726-c36d-cd05c0ea5339@redhat.com>
2017-02-13 12:55           ` Tedeschi, Walfred
2017-02-14 13:35         ` Tedeschi, Walfred
2017-02-14 13:59           ` Pedro Alves
2017-02-15 13:02             ` Tedeschi, Walfred
2017-02-15 13:15               ` Pedro Alves
2017-02-16 13:50                 ` Tedeschi, Walfred
2017-02-16 14:52                   ` Pedro Alves
2017-02-16 15:37                     ` Tedeschi, Walfred

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=9851a15e-b03a-7e5b-8415-87260120df9a@redhat.com \
    --to=palves@redhat.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=qiyaoltc@gmail.com \
    --cc=walfred.tedeschi@intel.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