From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20088 invoked by alias); 6 Oct 2014 15:48:52 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 20076 invoked by uid 89); 6 Oct 2014 15:48:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: na01-bn1-obe.outbound.protection.outlook.com Received: from mail-bn1on0146.outbound.protection.outlook.com (HELO na01-bn1-obe.outbound.protection.outlook.com) (157.56.110.146) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 06 Oct 2014 15:48:50 +0000 Received: from BN1PR0301MB0644.namprd03.prod.outlook.com (25.160.171.17) by BN1PR0301MB0642.namprd03.prod.outlook.com (25.160.171.15) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Mon, 6 Oct 2014 15:48:45 +0000 Received: from BN1PR0301MB0644.namprd03.prod.outlook.com ([25.160.171.17]) by BN1PR0301MB0644.namprd03.prod.outlook.com ([25.160.171.17]) with mapi id 15.00.1044.008; Mon, 6 Oct 2014 15:48:45 +0000 From: "rohitarulraj@freescale.com" To: Ulrich Weigand , "Maciej W. Rozycki" CC: Edmar Wienskoski , David Edelsohn , "gcc-patches@gcc.gnu.org" , Alan Modra , Jakub Jelinek , "rohitarulraj@freescale.com" Subject: RE: [RFC: Patch, PR 60102] [4.9/4.10 Regression] powerpc fp-bit ices@dwf_regno Date: Mon, 06 Oct 2014 15:48:00 -0000 Message-ID: <519007d57941439ca9e1356d9280e235@BN1PR0301MB0644.namprd03.prod.outlook.com> References: from "Maciej W. Rozycki" at Sep 28, 2014 11:23:18 PM <201409290943.s8T9hwpn030693@d06av02.portsmouth.uk.ibm.com> <6158af54375642a29548979a3cc420d1@BN1PR0301MB0644.namprd03.prod.outlook.com> In-Reply-To: <6158af54375642a29548979a3cc420d1@BN1PR0301MB0644.namprd03.prod.outlook.com> x-ms-exchange-transport-fromentityheader: Hosted x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR0301MB0642; x-forefront-prvs: 03569407CC x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(51704005)(199003)(24454002)(377454003)(189002)(5423002)(76482002)(86362001)(108616004)(99396003)(40100001)(120916001)(106356001)(64706001)(20776003)(21056001)(105586002)(106116001)(80022003)(101416001)(46102003)(10300001)(97736003)(85306004)(76576001)(33646002)(77096002)(85852003)(19580405001)(19580395003)(50986999)(87936001)(2656002)(76176999)(95666004)(54356999)(122556001)(66066001)(107046002)(99286002)(4396001)(74316001)(24736002);DIR:OUT;SFP:1102;SCL:1;SRVR:BN1PR0301MB0642;H:BN1PR0301MB0644.namprd03.prod.outlook.com;FPR:;MLV:sfv;PTR:InfoNoRecords;A:1;MX:1;LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-SW-Source: 2014-10/txt/msg00474.txt.bz2 > From: Dharmakan Rohit-B30502 > Sent: Monday, September 29, 2014 3:54 PM >=20 > > From: Ulrich Weigand [mailto:uweigand@de.ibm.com] Maciej W. Rozycki > > wrote: > > > On Mon, 4 Aug 2014, Edmar wrote: > > > > > > > Committed on trunk, revision 213596 Committed on 4.9 branch, > > > > revision 213597 > > > > > > This change regressed GDB for e500v2 multilibs, presumably because > > > it does not understand the new DWARF register numbers and does not > > > know how to map them to hardware registers. > > > > As I understand it, the change was supposed to only affect GCC > > internals, all externally generated debug info was supposed to remain > unchanged. > > > > If there are changes in debug info, something must have gone wrong. >=20 > Let me check if I can track this down. Maciej/Ulrich, I was able to narrow down the issue. Debug info generated with the current patch: <2><334>: Abbrev Number: 10 (DW_TAG_formal_parameter) <335> DW_AT_name : u=09 <337> DW_AT_decl_file : 1=09 <338> DW_AT_decl_line : 51=09 <339> DW_AT_type : <0x357>=09 <33d> DW_AT_location : 7 byte block: 90 7d 93 4 58 93 4 (DW_OP_r= egx: 125 (r125); DW_OP_piece: 4; DW_OP_reg8 (r8); DW_OP_piece: 4) Expected debug info: <2><334>: Abbrev Number: 10 (DW_TAG_formal_parameter) <335> DW_AT_name : u=09 <337> DW_AT_decl_file : 1=09 <338> DW_AT_decl_line : 51=09 <339> DW_AT_type : <0x359>=09 <33d> DW_AT_location : 8 byte block: 90 b8 9 93 4 58 93 4 (DW_OP= _regx: 1208 (r1208); DW_OP_piece: 4; DW_OP_reg8 (r8); DW_OP_piece: 4) While emitting the location descriptors of multiple registers (SPE high/low= part) individually, the GCC hard register number is converted in to DWARF = register number using "dbx_reg_number" [Statement "A", "B" & "C" below]. File1: gcc-4.9/gcc/config/rs6000/rs6000.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D ... /* Use standard DWARF numbering for DWARF debugging information. */ #define DBX_REGISTER_NUMBER(REGNO) rs6000_dbx_register_number (REGNO) -----= ----------------------------------------------------(A) ... File2: gcc-4.9/gcc/dwarf2out.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D /* Given an RTL of a register, return a location descriptor that designates a value that spans more than one register. */ static dw_loc_descr_ref multiple_reg_loc_descriptor (rtx rtl, rtx regs, enum var_init_status initialized) { ... /* Now onto stupid register sets in non contiguous locations. */ .... for (i =3D 0; i < XVECLEN (regs, 0); ++i) { dw_loc_descr_ref t; t =3D one_reg_loc_descriptor (dbx_reg_number (XVECEXP (regs, 0, i)), = VAR_INIT_STATUS_INITIALIZED); -------------------------------(B) ... } ..... =20=20 } static unsigned int dbx_reg_number (const_rtx rtl) { .... .... regno =3D DBX_REGISTER_NUMBER (regno); ----------------------------------= ---------------------------------------------------------------------------= (C) gcc_assert (regno !=3D INVALID_REGNUM); return regno; } File3:gcc-4.9/gcc/config/rs6000/sysv4.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D .... /* This target uses the sysv4.opt file. */ #define TARGET_USES_SYSV4_OPT 1 #undef DBX_REGISTER_NUMBER -------------------------------------------= ---------------------------------------------------------------(D) .... But statement "C" macro "DBX_REGISTER_NUMBER" gets undefined by statement "= D" hence the GCC hard register number gets emitted in the debug info instea= d of DWARF register number. Previously, without this patch for SPE high registers the GCC hard register= number was same as the DWARF register number (1200 onwards), hence we didn= 't see this issue. Removing statement "D" from "sysv4.h" file so as to generate expected DWAR= F register number does work, but will there be any side effects? Regards, Rohit