From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24250 invoked by alias); 24 Jun 2014 13:27:21 -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 24234 invoked by uid 89); 24 Jun 2014 13:27:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: na01-by2-obe.outbound.protection.outlook.com Received: from mail-by2lp0244.outbound.protection.outlook.com (HELO na01-by2-obe.outbound.protection.outlook.com) (207.46.163.244) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 24 Jun 2014 13:27:04 +0000 Received: from BN1BFFO11FD056.protection.gbl (10.58.144.31) by BN1BFFO11HUB024.protection.gbl (10.58.144.171) with Microsoft SMTP Server (TLS) id 15.0.969.12; Tue, 24 Jun 2014 13:26:59 +0000 Received: from xsj-pvapsmtpgw01 (149.199.60.83) by BN1BFFO11FD056.mail.protection.outlook.com (10.58.145.11) with Microsoft SMTP Server (TLS) id 15.0.969.12 via Frontend Transport; Tue, 24 Jun 2014 13:26:59 +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 1WzQkW-0002HP-I0; Tue, 24 Jun 2014 06:27:00 -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: Tue, 24 Jun 2014 13:27: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> In-Reply-To: <53A97330.4080708@redhat.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RCIS-Action: ALLOW Message-ID: <98b8d615-26b0-47eb-97e4-5f2391f9cfde@BN1BFFO11FD056.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)(438002)(199002)(51704005)(189002)(479174003)(377454003)(13464003)(33646001)(81542001)(74316001)(4396001)(2656002)(46406003)(87936001)(31966008)(74502001)(74662001)(21056001)(76482001)(46102001)(70736001)(81342001)(85306003)(19580405001)(77096002)(83322001)(19580395003)(44976005)(86362001)(23726002)(50986999)(76176999)(54356999)(85852003)(83072002)(104016002)(92726001)(77982001)(79102001)(92566001)(95666004)(97756001)(106466001)(47776003)(6806004)(99396002)(20776003)(64706001)(80022001)(50466002)(31696002)(53416004)(106116001)(93886003)(1496007)(23106004);DIR:OUT;SFP:;SCL:1;SRVR:BN1BFFO11HUB024;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: 02524402D6 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/msg00851.txt.bz2 -----Original Message----- From: Pedro Alves [mailto:palves@redhat.com]=20 Sent: Tuesday, June 24, 2014 6:17 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/24/2014 01:31 PM, Ajit Kumar Agarwal wrote: >> >> The default is choosen to assume stack protect to make compatible with t= he handling of stack protect registers in XMD Debugger. >=20 >>> But you've already added the G packet size guess for that. >=20 > In this case is it correct to say > If (tdesc =3D=3D NULL) > tdesc =3D tdesc_microblaze; >=20 > instead of tdesc_microblaze_with_stack_protect? Yes. >=20 >>> - >>> + if (tdesc_data !=3D NULL) >>> + { >>> + tdesc_use_registers (gdbarch, tdesc, tdesc_data); >>> + set_gdbarch_register_type (gdbarch,=20 >>> + microblaze_register_type); >> >>>> Hmm, why is this set_gdbarch_register_type call necessary? >> >> /* Override tdesc_register_type to adjust the types of VFP >> registers for NEON. */ >> This is done for arm target to set the different type for VFP=20 >> registers for Neon with Boolean flags is set before this call for VFP=20 >> registers. In the microblaze target it's not required for special=20 >> case of stack protect as > the microblaze_register_type always return builtin_int for these stack pr= otect registers. >=20 > Right. Actually, not right... This comment doesn't really appear to be correct: > In the microblaze target it's not required for special case of stack=20 > protect as the microblaze_register_type always return builtin_int for the= se stack protect registers. >>static struct type * >>microblaze_register_type (struct gdbarch *gdbarch, int regnum) { >>if (regnum =3D=3D MICROBLAZE_SP_REGNUM) >> return builtin_type (gdbarch)->builtin_data_ptr; >>if (regnum =3D=3D MICROBLAZE_PC_REGNUM) >>return builtin_type (gdbarch)->builtin_func_ptr; >>return builtin_type (gdbarch)->builtin_int; } What I meant the stack protect register are neither MICROBLAZE_SP_REGNUM no= r MICROBLAZE_PC_REGNUM so it always return register_type as builtin_int as = derived from the code. MICROBLAZE_SP_REGNUM and MICROBLAZE_PC_REGNUM clearly aren't builtin_int... >>Doesn't your patch change the output of "ptype $sp" and "ptype $pc" ? I will check this and add the changes mentioned below in xml files. That points at something missing in the target description: > + +name=3D"org.gnu.gdb.microblaze.core"> > + ... > + >>AFAICS, SP is "r1", and PC is "rpc". These should be marked with type=3D= "data_ptr" and type=3D"code_ptr" . Surely I will do this. >=20 >>>> As I mentioned before, please don't forget to document the new target = features in the manual. >> >> Would you mind in explaining which manual need to be changed for the new= target. >=20 >>> The GDB manual, gdb/doc/gdb.texinfo, describes all the standard XML tar= get features. See the "Standard Target Features" node, and add a new subse= ction for MicroBlaze. >=20 > Thanks !! I will add subsection for Microblaze target. Thank you. -- Pedro Alves