From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73114 invoked by alias); 11 Jun 2015 09:53:26 -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 72161 invoked by uid 89); 11 Jun 2015 09:53:25 -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: 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, 11 Jun 2015 09:53:22 +0000 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP; 11 Jun 2015 02:53:20 -0700 X-ExtLoop1: 1 Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by fmsmga001.fm.intel.com with ESMTP; 11 Jun 2015 02:53:18 -0700 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.171]) by IRSMSX151.ger.corp.intel.com ([169.254.4.102]) with mapi id 14.03.0224.002; Thu, 11 Jun 2015 10:53:10 +0100 From: "Tedeschi, Walfred" To: "Tedeschi, Walfred" , Joel Brobecker CC: "eliz@gnu.org" , "gdb-patches@sourceware.org" Subject: RE: [PATCH 1/1] Fix broken GDB build after adding Bound table support for i386. Date: Thu, 11 Jun 2015 09:53:00 -0000 Message-ID: References: <1433940196-22975-1-git-send-email-walfred.tedeschi@intel.com> <20150610141308.GB11014@adacore.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-06/txt/msg00205.txt.bz2 Joel, I am considering using a guard on the code like bellow: if (gdbarch_ptr_bit (gdbarch) =3D=3D 64) { #ifdef __x86_64__ mpx_bd_mask =3D MPX_BD_MASK; <- Here. MPX_BD_MASK is #define MPX_B= D_MASK 0xfffffff00000ULL /* select bits [47:20] */ bd_ptr_r_shift =3D 20; bd_ptr_l_shift =3D 3; bt_select_r_shift =3D 3; bt_select_l_shift =3D 5; bt_mask =3D MPX_BT_MASK; #else error(_("operation not supported yet") #endif } else { I consider that debugging a 64 bit application with a 32 bit debugger is no= t supported fully, but I might be wrong. In any case would this be an acceptable solution?=20 Thanks a lot and best regards, -Fred -----Original Message----- From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourceware= .org] On Behalf Of Tedeschi, Walfred Sent: Wednesday, June 10, 2015 4:56 PM To: Joel Brobecker Cc: eliz@gnu.org; gdb-patches@sourceware.org Subject: RE: [PATCH 1/1] Fix broken GDB build after adding Bound table supp= ort for i386. Joel, The message is this one: ---- /users/wtedesch/external/binutils-gdb/gdb/i386-tdep.c: In function 'i386_mp= x_get_bt_entry': /users/wtedesch/external/binutils-gdb/gdb/i386-tdep.c:8681:7: error: large = integer implicitly truncated to unsigned type [-Werror=3Doverflow] ---- Here is the reason: ----- if (gdbarch_ptr_bit (gdbarch) =3D=3D 64) { mpx_bd_mask =3D MPX_BD_MASK; <- Here. MPX_BD_MASK is #define MPX_B= D_MASK 0xfffffff00000ULL /* select bits [47:20] */ bd_ptr_r_shift =3D 20; bd_ptr_l_shift =3D 3; bt_select_r_shift =3D 3; bt_select_l_shift =3D 5; bt_mask =3D MPX_BT_MASK; } else { mpx_bd_mask =3D MPX_BD_MASK_32; bd_ptr_r_shift =3D 12; bd_ptr_l_shift =3D 2; bt_select_r_shift =3D 2; bt_select_l_shift =3D 4; bt_mask =3D MPX_BT_MASK_32; } ---- Thanks and regards, -Fred -----Original Message----- From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourceware= .org] On Behalf Of Joel Brobecker Sent: Wednesday, June 10, 2015 4:13 PM To: Tedeschi, Walfred Cc: eliz@gnu.org; gdb-patches@sourceware.org Subject: Re: [PATCH 1/1] Fix broken GDB build after adding Bound table supp= ort for i386. > Types used for some variables could not be used for 32 bits. > This patch changes uses larger types to accommodate the biggest=20 > integer possible. > Documentation was also affected, once a different version of texinfo=20 > the docs could not be build. >=20 > 2015-06-10 Walfred Tedeschi >=20 > * i386-tdep.c (i386_mpx_get_bt_entry): Exchange CORE_ADDR by > ULONGEST. >=20 > doc: > gdb.textinfo (i386): Fix "@end table" end and "@table" placement. Can you post the error messages, so we can understand why this is necessary= ? I'm also wondering whether you really want to return a CORE_ADDR which is= the sum of 2 ULONGEST now... -- Joel Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 5= 02 109 00) 600119052 Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052