public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: "Tedeschi, Walfred" <walfred.tedeschi@intel.com>
To: Pedro Alves <palves@redhat.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:31:00 -0000	[thread overview]
Message-ID: <e41833b7-33f9-12ab-41ec-2d35ae7e6f04@intel.com> (raw)
In-Reply-To: <9851a15e-b03a-7e5b-8415-87260120df9a@redhat.com>


Am 2/8/2017 um 4:21 PM schrieb Pedro Alves:
> 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.
BND registers should be restored to the values they had previous to the 
inferior call.
AFAIR that is the behaviour.

I will change the test to reflect more what you are proposing. Nice 
ideas have to be integrated!
Thanks a lot! :)
> 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.
Yes, will add the test!
> 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.
Agreed! I was considering that was default GDB functionality before.
But it is indeed interesting to test those cases. Being sure that also 
in this context
those functionalities are not broken. Thanks again!
> Lastly, shouldn't the manual say something about all this?
I think so, explaing what is expected for inferior calls in presence of 
MPX in general.
The entry should explain the case that you have pointed out above, right?
> Thanks,
> Pedro Alves
>

Thanks a lot for the valuable contribution,
/Fred
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

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

Thread overview: 19+ 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
2017-02-08 16:31         ` Tedeschi, Walfred [this message]
2017-02-13  8:33       ` Tedeschi, Walfred
2017-02-13 12:03         ` Pedro Alves
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
2017-02-16 16:15                       ` Pedro Alves
2017-02-16 16:41                         ` 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=e41833b7-33f9-12ab-41ec-2d35ae7e6f04@intel.com \
    --to=walfred.tedeschi@intel.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --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).