From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 328 invoked by alias); 24 Jun 2014 12:06:06 -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 319 invoked by uid 89); 24 Jun 2014 12:06:05 -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,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 24 Jun 2014 12:05:46 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5OC5gxl020686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 24 Jun 2014 08:05:42 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5OC5d8P014068; Tue, 24 Jun 2014 08:05:40 -0400 Message-ID: <53A96993.5040804@redhat.com> Date: Tue, 24 Jun 2014 12:06:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ajit Kumar Agarwal 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. 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> In-Reply-To: <57ebe4b0-83eb-4208-9778-472ecf0048d4@BY2FFO11FD038.protection.gbl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-06/txt/msg00842.txt.bz2 On 06/24/2014 11:28 AM, Ajit Kumar Agarwal wrote: >> + if (tdesc == NULL) >> + tdesc = tdesc_microblaze_with_stack_protect; > > Shouldn't the default be to _not_ assume stack protect ? > > The default is choosen to assume stack protect to make compatible with the handling of stack protect registers in XMD Debugger. But you've already added the G packet size guess for that. >> - >> + if (tdesc_data != NULL) >> + { >> + tdesc_use_registers (gdbarch, tdesc, tdesc_data); >> + set_gdbarch_register_type (gdbarch, 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 registers for Neon with Boolean flags is set before this call for VFP registers. In the microblaze target it's not required for special case of stack protect as the microblaze_register_type always return builtin_int for these stack protect registers. > > Right. >>> 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. The GDB manual, gdb/doc/gdb.texinfo, describes all the standard XML target features. See the "Standard Target Features" node, and add a new subsection for MicroBlaze. -- Pedro Alves