From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25308 invoked by alias); 30 Jun 2014 16:29: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 25290 invoked by uid 89); 30 Jun 2014 16:29:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 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-bn1lp0140.outbound.protection.outlook.com (HELO na01-bn1-obe.outbound.protection.outlook.com) (207.46.163.140) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 30 Jun 2014 16:29:07 +0000 Received: from BY2FFO11FD050.protection.gbl (10.1.14.34) by BY2FFO11HUB028.protection.gbl (10.1.14.139) with Microsoft SMTP Server (TLS) id 15.0.969.12; Mon, 30 Jun 2014 16:29:02 +0000 Received: from xsj-pvapsmtpgw01 (149.199.60.83) by BY2FFO11FD050.mail.protection.outlook.com (10.1.15.187) with Microsoft SMTP Server (TLS) id 15.0.969.12 via Frontend Transport; Mon, 30 Jun 2014 16:29:03 +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 1X1eRr-00038e-VV; Mon, 30 Jun 2014 09:28:55 -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: Mon, 30 Jun 2014 16:29: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> <736c2e0d-6ff1-40c3-8120-dc6f5d91e6b1@BL2FFO11FD052.protection.gbl> <53A8290A.1050701@redhat.com> <53A94147.4050700@redhat.com> <57ebe4b0-83eb-4208-9778-472ecf0048d4@BY2FFO11FD038.protection.gbl> <53A96993.5040804@redhat.com> <109c35c1-e2f6-430f-9235-c6c82a93daf1@BL2FFO11FD009.protection.gbl> <53A97330.4080708@redhat.com> <53B1420A.40501@redhat.com> <53B1488B.7070007@redhat.com> In-Reply-To: <53B1488B.7070007@redhat.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RCIS-Action: ALLOW Message-ID: X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:149.199.60.83;CTRY:US;IPV:NLI;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(6009001)(438002)(13464003)(51704005)(199002)(189002)(377454003)(479174003)(24454002)(76482001)(46406003)(79102001)(2656002)(92566001)(74316001)(87936001)(21056001)(20776003)(76176999)(64706001)(106466001)(6806004)(77982001)(97756001)(19580395003)(83072002)(50466002)(47776003)(92726001)(23726002)(99396002)(19580405001)(54356999)(74502001)(77096002)(83322001)(70736001)(53416004)(1496007)(106116001)(81342001)(50986999)(85306003)(85852003)(93886003)(95666004)(80022001)(33646001)(31696002)(44976005)(104016002)(74662001)(4396001)(107046002)(86362001)(81542001)(31966008)(46102001)(107986001);DIR:OUT;SFP:;SCL:1;SRVR:BY2FFO11HUB028;H:xsj-pvapsmtpgw01;FPR:;MLV:sfv;PTR:unknown-60-83.xilinx.com;A:1;MX:1;LANG:en; X-OriginatorOrg: xilinx.onmicrosoft.com X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0258E7CCD4 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/msg00964.txt.bz2 -----Original Message----- From: Pedro Alves [mailto:palves@redhat.com]=20 Sent: Monday, June 30, 2014 4:53 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/30/2014 12:13 PM, Ajit Kumar Agarwal wrote: > -----Original Message----- > From: Pedro Alves [mailto:palves@redhat.com] > Sent: Monday, June 30, 2014 4:25 PM > To: Ajit Kumar Agarwal > Cc: gdb-patches@sourceware.org; Michael Eager; Vinod Kathail;=20 > Vidhumouli Hunsigida; Nagaraju Mekala > Subject: Re: [Patch, microblaze]: Fix for remote G Packet message too lon= g error for baremetal. >=20 > On 06/30/2014 11:32 AM, Ajit Kumar Agarwal wrote: >> Signed-off-by:Ajit Agarwal ajitkum@xilinx.com >> >>>> In this case is it correct to say >>>> If (tdesc =3D=3D NULL) >>>> tdesc =3D tdesc_microblaze; >>>> >>>> instead of tdesc_microblaze_with_stack_protect? >>>>>> Yes. >> Instead of tdesc_microblaze_with_stack_protect if I use tdesc_microblaze= the "G Packet message is too long" error is not resolved. >=20 >>> Then it sounds like the G packet size guesses you're adding aren't actu= ally triggering. Why? >=20 > I have checked the guesses are actually triggering as it works fine=20 > with backward compatibility with the Designs there is no stack-protect re= gisters. For the Design that has the Stack protect register, it reports the= message " G packet too long ". >>If the G guess is triggering OK, and so GDB picks the description with th= e stack protect registers based on the G packet size, why would the default= target description matter at all? If it >>does, then something sounds bro= ken. In Microblaze Port the gdbarch_info has tdesc always set to NULL. Thus th= e gdbarch_init doesn't populates the register info based feature target des= cription. Though the microblaze_register_g_packet_guesses is called by gdba= rch_init and register the guesses, but the gdbarch_info.tdesc =3D=3D NULL= always and features target description info is populated based on default= target description. >>What are you doing different from the other ports that use this mechanism? In Microblaze port as compared to other architecture port lacking the funct= ion microblaze_read_description which sets the tdesc and the architecture s= et up based the Linux Kernel and Ptrace parameters. The other architecture = like ARM and MIPS has arm_read_description and arm_linux_read_description= which sets the tdesc info current()->Process. >>Please debug this a bit further. -- Pedro Alves