From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49283 invoked by alias); 17 Dec 2015 16:44:55 -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 49273 invoked by uid 89); 17 Dec 2015 16:44:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=eliz@gnu.org, U*eliz, elizgnuorg X-HELO: mga09.intel.com Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 17 Dec 2015 16:44:53 +0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 17 Dec 2015 08:44:50 -0800 X-ExtLoop1: 1 Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by orsmga001.jf.intel.com with ESMTP; 17 Dec 2015 08:44:49 -0800 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.138]) by IRSMSX106.ger.corp.intel.com ([169.254.8.228]) with mapi id 14.03.0248.002; Thu, 17 Dec 2015 16:44:48 +0000 From: "Tedeschi, Walfred" To: Eli Zaretskii CC: "brobecker@adacore.com" , "gdb-patches@sourceware.org" Subject: RE: [PATCH V2] ABI changes for MPX. Date: Thu, 17 Dec 2015 16:44:00 -0000 Message-ID: References: <1450358624-11596-1-git-send-email-walfred.tedeschi@intel.com> <83bn9pyqv8.fsf@gnu.org> In-Reply-To: <83bn9pyqv8.fsf@gnu.org> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg00341.txt.bz2 Eli, Thanks for your review! Explaining a bit more: Where this initialization comes into play is when you are in the middle of = a function that returns a pointer. You issue the command "return a", where a is a pointer. BND0 should contain that boundary of a, but it will in fact return any valu= e presented in the register at that moment. In this way application will be in a not good state. Continuing the execut= ion the user might have a bound violation due to the return. This behaviour is when the " mpx-bnd-init-on-return" is 0. In case the " mpx-bnd-init-on-return" is 1 the BND0 will be set to zero, IN= IT state, and the pointer a will be able to access the whole memory. Thanks again, -Fred -----Original Message----- From: Eli Zaretskii [mailto:eliz@gnu.org]=20 Sent: Thursday, December 17, 2015 5:36 PM To: Tedeschi, Walfred Cc: brobecker@adacore.com; gdb-patches@sourceware.org Subject: Re: [PATCH V2] ABI changes for MPX. > From: Walfred Tedeschi > Cc: gdb-patches@sourceware.org, Walfred Tedeschi=20 > > Date: Thu, 17 Dec 2015 14:23:44 +0100 >=20 > Code reflects what is presented in the ABI document: > https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI > Here new class POINTER was added. GDB code is modified to mirror this=20 > new class. (page 134) >=20 > When using the return command, execution of a function is aborted and=20 > present values are returned from that point. That can cause bound=20 > violations in the MPX context. To avoid such side-effects a new set=20 > variable was added "mpx-bnd-init-on-return" which controls the=20 > initialization of bound register when using the return command. >=20 > As bound initialization it is understood the set of the BND register=20 > to zero allowing the associated pointer to access the whole memory. >=20 > As default the value of "mpx-bnd-init-on-return" is set to 1. So=20 > bound register are initilized when using the "return" command. Thanks. Review comments for the documentation parts follow: > + add_setshow_boolean_cmd ("mpx-bnd-init-on-return", no_class, > + &mpx_bnd_init_on_return, _("\ > +Set the bnd registers to INIT state when returning from a call."),=20 > +_("\ I think "bnd" should be "BND", in caps. > +Show the state of the mpx-bnd-init-on-return."), We usually repeat here the same text as in the "Set" part, except replace "= Set" with "Show". So something like Show whether BND registers are set to INIT state when returning from a cal= l. will be better. > +While calling functions from the debugger, of an Intel(R) MPX enabled=20 > +program, boundary registers have to be initialized before performing=20 > +the call, to avoid boundary violations while performing the call. A=20 > +bound is defined to be "bound" or "boundary"? You use the latter in the previous text. > +initialized when the pointer associated to that boundary can access=20 > +the whole memory, in this case the register bound register associated=20 > +to it has value 0, e.g. if the register associated is bnd0raw its value = will be @{0x0, 0x0@}. Suggest to break this into 3 separate sentences, as this is too complex for= a single one. > +It is possible to change the boundary values, if desired, by placing=20 > +a breakpoint at prologue's end and setting bound registers as wished. Are we sure every reader will immediately know how to set a breakpoint "at = prologue's end"? If not, perhaps a hint or a cross-reference to where this= is explained is in order. > +After the call is performed bound register might be keept or not for=20 > +further investigations. Typo: "keept" should be "kept". I also don't understand what this sentence is trying to explain. Can you c= larify? > +While the using the @command{return} bounds can propagate through "When", not "while". And please delete the "the" before "using". > +execution causing a boundary violation. > +The behaviour of initializing bounds when using @command{return} can=20 > +be controlled and vizualized via the following commands: ^^^^^^^^^^ Typo: should be "visualized". > +@table @code > +@kindex set mpx-bnd-init-on-return > +When set to 1 bound registers will be initialized when returning from=20 > +a calling a program function @kindex show mpx-bnd-init-on-return Show=20 > +the state of mpx-bnd-init-on-return. > +@end table I didn't quite understand the effect and the need in this variable. Can you clarify, please? 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