From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41065 invoked by alias); 21 Jan 2016 17:34:21 -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 41052 invoked by uid 89); 21 Jan 2016 17:34:20 -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_PASS autolearn=ham version=3.3.2 spammy=H*r:sk:wtedesc, H*r:ip*10.7.209.21, H*RU:HELO, Hx-spam-relays-external:HELO 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, 21 Jan 2016 17:34:19 +0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 21 Jan 2016 09:34:16 -0800 X-ExtLoop1: 1 Received: from wtedesch-mobl2.ger.corp.intel.com (HELO [172.28.205.68]) ([172.28.205.68]) by orsmga002.jf.intel.com with ESMTP; 21 Jan 2016 09:34:13 -0800 Message-ID: <56A11694.4000502@intel.com> Date: Thu, 21 Jan 2016 17:34:00 -0000 From: Walfred Tedeschi User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Eli Zaretskii , "palves"@redhat.com, brobecker@adacore.com, gdb-patches@sourceware.org Subject: Re: FW: [PATCH V4 6/6] Intel MPX bound violation handling. References: <1453387705-6597-1-git-send-email-walfred.tedeschi@intel.com> <1453387705-6597-7-git-send-email-walfred.tedeschi@intel.com> <83vb6m9a0u.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format="flowed" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00543.txt.bz2 > -----Original Message----- > From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourcewa= re.org] On Behalf Of Eli Zaretskii > Sent: Thursday, January 21, 2016 5:23 PM > To: Tedeschi, Walfred > Cc: palves@redhat.com; brobecker@adacore.com; gdb-patches@sourceware.org > Subject: Re: [PATCH V4 6/6] Intel MPX bound violation handling. > >> From: Walfred Tedeschi >> Cc: gdb-patches@sourceware.org, Walfred Tedeschi >> >> Date: Thu, 21 Jan 2016 15:48:25 +0100 >> >> --- a/gdb/NEWS >> +++ b/gdb/NEWS >> @@ -3,6 +3,21 @@ >>=20=20=20 >> *** Changes since GDB 7.10 >>=20=20=20 >> +* Intel MPX boud violation handler. >> + >> + A boundary violations is presented to the inferior as >> + a segmentation fault having SIGCODE 3. In this case > ^^ Two spaces between sentenc= es, please. ok! >> + GDB displays also the kind of violation (upper or lower), >> + bounds, poiter value and the memory accessed, besides displaying > ^^^^^^ > "pointer" > >> + the usual signal received and code location report. >> + >> + As exemplified below: >> + Program received signal SIGSEGV, Segmentation fault >> + upper bound violation - bounds {lbound =3D 0x603010, ubound =3D 0x60= 3023} >> + accessing 0x60302f. >> + 0x0000000000400d7c in upper (p=3D0x603010, a=3D0x603030, b=3D0x60305= 0, >> + c=3D0x603070, d=3D0x603090, len=3D7) at i386-mpx-sigsegv.c:68 > May I suggest to say > > accessing address 0x60302f. > > instead? That would be more clear, I think. I will change it, yes, it is better. >> --- a/gdb/doc/gdb.texinfo >> +++ b/gdb/doc/gdb.texinfo >> @@ -22267,6 +22267,57 @@ whose bounds are to be changed, @var{lbound} >> and @var{ubound} are new values for lower and upper bounds respectively. >> @end table >>=20=20=20 >> + >> +A boundary violation is presented to the inferior as a segmentation >> +fault having SIGCODE 3. @value{GDBN} may display additional > ^^ Two spaces. > >> +information is displayed in this case. > "...may display additional information is displayed..."? One of the "dis= play" and "displayed" is redundant here, I think. I will change to "may display additional information " >> + On @code{STOP} mode >> +@value{GDBN} will also display the kind of violation: "upper" or >> +"lower", bounds, pointer value and the address accessed. >> +On @code{NOSTOP} no additional information will be presented. > I suggest to say "In STOP mode" and "In NOSTOP mode". "In", not "On". Right! > >> +The usual output of a segfault is: >> +@smallexample >> +Program received signal SIGSEGV, Segmentation fault >> +0x0000000000400d7c in upper (p=3D0x603010, a=3D0x603030, b=3D0x603050, >> +c=3D0x603070, d=3D0x603090, len=3D7) at i386-mpx-sigsegv.c:68 >> +68 value =3D *(p + len); >> +@end smallexample >> + >> +In case it is a bound violation it will be presented as: >> +@smallexample >> +Program received signal SIGSEGV, Segmentation fault upper bound >> +violation - bounds @{lbound =3D 0x603010, ubound =3D 0x603023@} accessi= ng >> +0x60302f. >> +0x0000000000400d7c in upper (p=3D0x603010, a=3D0x603030, b=3D0x603050, >> +c=3D0x603070, d=3D0x603090, len=3D7) at i386-mpx-sigsegv.c:68 >> +68 value =3D *(p + len); >> +@end smallexample > Why do we need to show here the output when no bound violation happened? > > Actually, why not move this description and the example to the "Signals" = node? If I were a user who received such a notification, the "Signals" nod= e is where I would look for the explanations first. I will move it there. About the example I wanted to show where the=20 change will be placed. If you consider that this is superfluous, no=20 issue in removing. Will the snippet bellow be better? Program received signal SIGSEGV, Segmentation fault upper bound violation - bounds @{lbound =3D 0x603010, ubound =3D 0x603023@} accessing 0x60302f. > Thanks. Thanks and regards, -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