From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12388 invoked by alias); 18 Jun 2014 15:57:52 -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 12377 invoked by uid 89); 18 Jun 2014 15:57:51 -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,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: na01-bn1-obe.outbound.protection.outlook.com Received: from mail-bn1blp0184.outbound.protection.outlook.com (HELO na01-bn1-obe.outbound.protection.outlook.com) (207.46.163.184) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 18 Jun 2014 15:57:49 +0000 Received: from BN1BFFO11FD031.protection.gbl (10.58.144.33) by BN1BFFO11HUB062.protection.gbl (10.58.144.209) with Microsoft SMTP Server (TLS) id 15.0.959.15; Wed, 18 Jun 2014 15:57:46 +0000 Received: from xsj-pvapsmtpgw01 (149.199.60.83) by BN1BFFO11FD031.mail.protection.outlook.com (10.58.144.94) with Microsoft SMTP Server (TLS) id 15.0.969.12 via Frontend Transport; Wed, 18 Jun 2014 15:57:45 +0000 Received: from unknown-38-66.xilinx.com ([149.199.38.66] helo=xsj-smtp1) by xsj-pvapsmtpgw01 with esmtp (Exim 4.63) (envelope-from ) id 1WxIFI-0000yj-3V; Wed, 18 Jun 2014 08:57:56 -0700 From: Ajit Kumar Agarwal To: Pedro Alves CC: "gdb-patches@sourceware.org" , Michael Eager , Vinod Kathail , Vidhumouli Hunsigida , Nagaraju Mekala Subject: RE: [Patch, microblaze]: Fix for remote G Packet message too long error for baremetal. Date: Wed, 18 Jun 2014 15:57:00 -0000 References: <53A023B1.5000105@redhat.com> <859f27cb-8c46-46c1-9625-7287c60f3ae9@BY2FFO11FD007.protection.gbl> <53A1ABF0.9080004@redhat.com> <74281fd5-518a-4d7f-977a-6fa1320f6db9@BY2FFO11FD016.protection.gbl> <53A1B61F.9080803@redhat.com> In-Reply-To: <53A1B61F.9080803@redhat.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RCIS-Action: ALLOW Message-ID: <61827eac-4100-48e5-957f-94b11b8cf899@BN1BFFO11FD031.protection.gbl> X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:149.199.60.83;CTRY:US;IPV:NLI;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(6009001)(438001)(13464003)(24454002)(479174003)(377454003)(189002)(199002)(74502001)(87936001)(2656002)(76482001)(74662001)(95666004)(21056001)(93886003)(104016002)(46406003)(77096002)(1496007)(83072002)(46102001)(53416004)(4396001)(97756001)(92726001)(81542001)(92566001)(85852003)(23726002)(20776003)(81342001)(70736001)(47776003)(79102001)(33646001)(50466002)(74316001)(80022001)(31966008)(64706001)(31696002)(50986999)(77982001)(76176999)(54356999)(99396002)(83322001)(44976005)(19580405001)(86362001)(19580395003)(6806004)(85306003);DIR:OUT;SFP:;SCL:1;SRVR:BN1BFFO11HUB062;H:xsj-pvapsmtpgw01;FPR:;MLV:sfv;PTR:unknown-60-83.xilinx.com;MX:1;A:1;LANG:en; X-OriginatorOrg: xilinx.onmicrosoft.com X-Microsoft-Antispam: BL:0;ACTION:Default;RISK:Low;SCL:0;SPMLVL:NotSpam;PCL:0;RULEID: X-Forefront-PRVS: 02462830BE Received-SPF: Pass (: domain of xilinx.com designates 149.199.60.83 as permitted sender) receiver=; client-ip=149.199.60.83; helo=xsj-pvapsmtpgw01; Authentication-Results: spf=pass (sender IP is 149.199.60.83) smtp.mailfrom=ajit.kumar.agarwal@xilinx.com; X-SW-Source: 2014-06/txt/msg00677.txt.bz2 Thanks for the clarifications and comments. I will incorporate the change. Thanks & Regards Ajit -----Original Message----- From: Pedro Alves [mailto:palves@redhat.com]=20 Sent: Wednesday, June 18, 2014 9:24 PM To: Ajit Kumar Agarwal Cc: gdb-patches@sourceware.org; Michael Eager; Vinod Kathail; Vidhumouli Hu= nsigida; Nagaraju Mekala Subject: Re: [Patch, microblaze]: Fix for remote G Packet message too long = error for baremetal. On 06/18/2014 04:39 PM, Ajit Kumar Agarwal wrote: > The info registers against such a stub( where the design does not=20 > have stack-protect registers) shows the registers $rshr and $rslr but=20 > it shows as . Is the display of $rshr and $rslr=20 > happening because of this second guess with -2 case? Yes, because you're guessing a target description that includes the registe= rs. Is it inappropriate to have the second guess with -2 case? It is, but you're guessing the wrong description... In addition to tdesc_microblaze_with_stack_protect, create _another_ descri= ption that does _not_ xi:include the stack protect feature, and register th= e guess with that: microblaze_register_g_packet_guesses (struct gdbarch *gdbarch) { register_remote_g_packet_guess (gdbarch, MICROBLAZE_NUM_REGS, tdesc_microblaze_with_stack_protect); register_remote_g_packet_guess (gdbarch, MICROBLAZE_NUM_REGS - 2, tdesc_microblaze); } I'd add a MICROBLAZE_NUM_CORE_REGS value to the registers enum. Then inste= ad of that magic " - 2", you could write: { register_remote_g_packet_guess (gdbarch, MICROBLAZE_NUM_CORE_REGS, tdesc_microblaze); register_remote_g_packet_guess (gdbarch, MICROBLAZE_NUM_REGS, tdesc_microblaze_with_stack_protect); -- Pedro Alves