From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30152 invoked by alias); 24 Jun 2014 12:46:48 -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 30141 invoked by uid 89); 24 Jun 2014 12:46:47 -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:46:46 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5OCkhSp001353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 24 Jun 2014 08:46:43 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5OCkeKV009620; Tue, 24 Jun 2014 08:46:41 -0400 Message-ID: <53A97330.4080708@redhat.com> Date: Tue, 24 Jun 2014 12:46: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> <53A96993.5040804@redhat.com> <109c35c1-e2f6-430f-9235-c6c82a93daf1@BL2FFO11FD009.protection.gbl> In-Reply-To: <109c35c1-e2f6-430f-9235-c6c82a93daf1@BL2FFO11FD009.protection.gbl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-06/txt/msg00844.txt.bz2 On 06/24/2014 01:31 PM, Ajit Kumar Agarwal wrote: >> >> 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. > > In this case is it correct to say > If (tdesc == NULL) > tdesc = tdesc_microblaze; > > instead of tdesc_microblaze_with_stack_protect? Yes. > >>> - >>> + 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. 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 protect as > the microblaze_register_type always return builtin_int for these stack protect registers. static struct type * microblaze_register_type (struct gdbarch *gdbarch, int regnum) { if (regnum == MICROBLAZE_SP_REGNUM) return builtin_type (gdbarch)->builtin_data_ptr; if (regnum == MICROBLAZE_PC_REGNUM) return builtin_type (gdbarch)->builtin_func_ptr; return builtin_type (gdbarch)->builtin_int; } 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" ? That points at something missing in the target description: > + > + > + ... > + AFAICS, SP is "r1", and PC is "rpc". These should be marked with type="data_ptr" and type="code_ptr" . > >>>> 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. > > Thanks !! I will add subsection for Microblaze target. Thank you. -- Pedro Alves