From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63045 invoked by alias); 16 Dec 2015 15:21:33 -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 63029 invoked by uid 89); 16 Dec 2015 15:21:32 -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 X-HELO: mga14.intel.com Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 16 Dec 2015 15:21:31 +0000 Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 16 Dec 2015 07:21:29 -0800 X-ExtLoop1: 1 Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by FMSMGA003.fm.intel.com with ESMTP; 16 Dec 2015 07:21:28 -0800 Received: from irsmsx112.ger.corp.intel.com (10.108.20.5) by IRSMSX151.ger.corp.intel.com (163.33.192.59) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 16 Dec 2015 15:19:40 +0000 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.138]) by irsmsx112.ger.corp.intel.com ([169.254.1.8]) with mapi id 14.03.0248.002; Wed, 16 Dec 2015 15:19:40 +0000 From: "Tedeschi, Walfred" To: 'Pedro Alves' , 'Joel Brobecker' CC: "'gdb-patches@sourceware.org'" Subject: RE: [PATCH v1] Intel(R) MPX - Bound violation handling. Date: Wed, 16 Dec 2015 15:21:00 -0000 Message-ID: References: <1445864086-4831-1-git-send-email-walfred.tedeschi@intel.com> <1445864086-4831-4-git-send-email-walfred.tedeschi@intel.com> <20151119000134.GB7958@adacore.com> <566F0E37.8090905@redhat.com> In-Reply-To: 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/msg00298.txt.bz2 Pedro, We have found an interesting fact, changing the order the observer_notify_s= ignal_recieved from about line 8170 to just before Observer_notify_normal_stop. Allows the evaluation of the siginfo without = the stop. Looking at the code I could not see anything could harm there. What do you think? Is moving that code a possibility? Thanks and regards, -Fred=20 -----Original Message----- From: Tedeschi, Walfred=20 Sent: Tuesday, December 15, 2015 11:59 AM To: Pedro Alves; Joel Brobecker Cc: gdb-patches@sourceware.org Subject: RE: [PATCH v1] Intel(R) MPX - Bound violation handling. Pedro, It comes from the infrun.c (validate_siginfo_access) . The requirement is not running is not fulfilled. Also in the case that we e= xecute a lookup_interval and ask for value_contents we trigger the same cod= e. What would be the suggestion here: Additional function to be used internally in infrun or add a flag. Thanks a lot for your comments and insights! Best regards, -Fred -----Original Message----- From: Pedro Alves [mailto:palves@redhat.com]=20 Sent: Monday, December 14, 2015 7:45 PM To: Tedeschi, Walfred; Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v1] Intel(R) MPX - Bound violation handling. On 12/14/2015 05:43 PM, Tedeschi, Walfred wrote: > Joel and Pedro, >=20 > Thanks a lot for your feedback! >=20 > I Could address most of the comments in here.=20 > An important one is still missing, namely this one: >=20 >> +{ >> + long si_code; >> + struct regcache *regcache =3D get_current_regcache (); >> + struct gdbarch *gdbarch =3D get_regcache_arch (regcache); >> + >> + set_running (user_visible_resume_ptid (1), 0); >=20 > This is the part that _really_ concerns me, not necessary because I think= it's wrong (although, it is a big red flag for me), but because I don't un= derstand why it's needed, and how it will affect things. > (From Joel) >> + si_code =3D parse_and_eval_long ("$_siginfo.si_code\n"); >=20 > During the debugging time I understood that inferior was stopped. Gdb is = that was in the process to determine in which state the inferior was. > In this sense I set the flag at this point to allow for the evaluation. Where is the error thrown that required brute-forcing set_running away? Can we try to find some other way to handle this? E.g., use something a bi= t lower level than parse_and_eval_long that bypasses the error? E.g., star= t from lookup_internalvar and then use type/value manipulation routines? Thanks, Pedro Alves >=20 > I also looked in gdb for error handling while performing evaluations but = did not find anything. > I am considering that the way to proceed is to use TRY and CATCH blocks. = Would you recommend that? >=20 > Thanks and regards, 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