From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105197 invoked by alias); 21 Jan 2016 16:23:24 -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 105178 invoked by uid 89); 21 Jan 2016 16:23:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=321, 36, 3,6, HX-Received-From:4830 X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 21 Jan 2016 16:23:21 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMI0y-0008W5-50 for gdb-patches@sourceware.org; Thu, 21 Jan 2016 11:23:19 -0500 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMI0x-0008Vv-N9; Thu, 21 Jan 2016 11:23:16 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4351 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aMI0w-0000yZ-Vv; Thu, 21 Jan 2016 11:23:15 -0500 Date: Thu, 21 Jan 2016 16:23:00 -0000 Message-Id: <83vb6m9a0u.fsf@gnu.org> From: Eli Zaretskii To: Walfred Tedeschi CC: palves@redhat.com, brobecker@adacore.com, gdb-patches@sourceware.org In-reply-to: <1453387705-6597-7-git-send-email-walfred.tedeschi@intel.com> (message from Walfred Tedeschi on Thu, 21 Jan 2016 15:48:25 +0100) Subject: Re: [PATCH V4 6/6] Intel MPX bound violation handling. Reply-to: Eli Zaretskii References: <1453387705-6597-1-git-send-email-walfred.tedeschi@intel.com> <1453387705-6597-7-git-send-email-walfred.tedeschi@intel.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00540.txt.bz2 > 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 @@ > > *** Changes since GDB 7.10 > > +* 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 sentences, please. > + 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 = 0x603010, ubound = 0x603023} > + accessing 0x60302f. > + 0x0000000000400d7c in upper (p=0x603010, a=0x603030, b=0x603050, > + c=0x603070, d=0x603090, len=7) at i386-mpx-sigsegv.c:68 May I suggest to say accessing address 0x60302f. instead? That would be more clear, I think. > --- 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 > > + > +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 "display" and "displayed" is redundant here, I think. > + 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". > +The usual output of a segfault is: > +@smallexample > +Program received signal SIGSEGV, Segmentation fault > +0x0000000000400d7c in upper (p=0x603010, a=0x603030, b=0x603050, > +c=0x603070, d=0x603090, len=7) at i386-mpx-sigsegv.c:68 > +68 value = *(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 = 0x603010, ubound = 0x603023@} > +accessing 0x60302f. > +0x0000000000400d7c in upper (p=0x603010, a=0x603030, b=0x603050, > +c=0x603070, d=0x603090, len=7) at i386-mpx-sigsegv.c:68 > +68 value = *(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" node is where I would look for the explanations first. Thanks.