From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22351 invoked by alias); 17 Dec 2015 17:31:14 -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 22331 invoked by uid 89); 17 Dec 2015 17:31:13 -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=H*r:169.254.2, gdbpatchesownersourcewareorg, gdb-patches-owner@sourceware.org, U*gdb-patches-owner X-HELO: mga11.intel.com Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 17 Dec 2015 17:31:12 +0000 Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP; 17 Dec 2015 09:31:12 -0800 X-ExtLoop1: 1 Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga003.jf.intel.com with ESMTP; 17 Dec 2015 09:31:09 -0800 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.138]) by IRSMSX102.ger.corp.intel.com ([169.254.2.251]) with mapi id 14.03.0248.002; Thu, 17 Dec 2015 17:31:08 +0000 From: "Tedeschi, Walfred" To: Pedro Alves , "Joel Brobecker (brobecker@adacore.com)" CC: "gdb-patches@sourceware.org" Subject: RE: [PATCH v1] Intel(R) MPX - Bound violation handling. Date: Thu, 17 Dec 2015 17:31: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> <567196E6.9040602@redhat.com> In-Reply-To: <567196E6.9040602@redhat.com> 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/msg00351.txt.bz2 Pedro, We have lost the print when not stopping, by doing that. Idea was also to print in that case. Any idea how we could also handle the other case? For the stopping case all seems fine. Will run tests again to be sure. Thanks and regards, -Fred -----Original Message----- From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourceware= .org] On Behalf Of Pedro Alves Sent: Wednesday, December 16, 2015 5:53 PM To: Tedeschi, Walfred; 'Joel Brobecker' Cc: 'gdb-patches@sourceware.org' Subject: Re: [PATCH v1] Intel(R) MPX - Bound violation handling. On 12/16/2015 03:19 PM, Tedeschi, Walfred wrote: > Pedro, >=20 > We have found an interesting fact, changing the order the=20 > observer_notify_signal_recieved from about line 8170 to just before Obser= ver_notify_normal_stop. Allows the evaluation of the siginfo without the s= top. That's because we're about to present a stop to the user, so we mark the th= reads as stopped in between: /* Let the user/frontend see the threads as stopped. */ do_cleanups (old_chain); But there's another observer_notify_signal_received call that is done while= threads are still marked running. Here when we print the signal, but don'= t stop: /* Notify observers the signal has "handle print" set. Note we returned early above if stopping; normal_stop handles the printing in that case. */ if (signal_print[ecs->event_thread->suspend.stop_signal]) { /* The signal table tells us to print about this signal. */ target_terminal_ours_for_output (); observer_notify_signal_received (ecs->event_thread->suspend.stop_signal); target_terminal_inferior (); } Should gdb print the extra info in that case? In any case, for the normal_stop case, I think you'd want to move the obser= vers call to just after the do_cleanups call shown above. At least, put it before the stop hook handling. If something sets the targ= et running in the stop hook, then you'd lose stopped_by_random_signal. > Looking at the code I could not see anything could harm there. This may change output order, both CLI and MI. Please actually try using t= he resulting gdb to intercept a signal, and compare it with an unpatched gd= b. Also, running the testsuite wouldn't be a bad idea... >=20 > What do you think? Is moving that code a possibility? Thanks, Pedro Alves 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