From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2272 invoked by alias); 8 Feb 2017 16:21:47 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 2162 invoked by uid 89); 8 Feb 2017 16:21:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=behave, resumed, _after_, interrupted X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 08 Feb 2017 16:21:45 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C6ACA4E4FC; Wed, 8 Feb 2017 16:21:45 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v18GLhT2023265; Wed, 8 Feb 2017 11:21:44 -0500 Subject: Re: [PATCH V7] amd64-mpx: initialize bnd register before performing inferior calls. To: "Tedeschi, Walfred" , qiyaoltc@gmail.com, brobecker@adacore.com References: <1485875613-31975-1-git-send-email-walfred.tedeschi@intel.com> <53d42bb6-3b83-6213-4087-6d30e7d837de@redhat.com> <217a8c13-b7d0-7fe6-56b5-85ff53ce097a@intel.com> <88c7180f-8843-a148-425a-2adf56c6d0bf@redhat.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <9851a15e-b03a-7e5b-8415-87260120df9a@redhat.com> Date: Wed, 08 Feb 2017 16:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <88c7180f-8843-a148-425a-2adf56c6d0bf@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-02/txt/msg00191.txt.bz2 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