From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5871 invoked by alias); 22 May 2014 19:44:50 -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 5850 invoked by uid 89); 22 May 2014 19:44:49 -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_NONE autolearn=ham version=3.3.2 X-HELO: homiemail-a94.g.dreamhost.com Received: from sub5.mail.dreamhost.com (HELO homiemail-a94.g.dreamhost.com) (208.113.200.129) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 22 May 2014 19:44:47 +0000 Received: from homiemail-a94.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a94.g.dreamhost.com (Postfix) with ESMTP id C76B538A059; Thu, 22 May 2014 12:44:45 -0700 (PDT) Received: from redwood.eagercon.com (c-24-7-16-38.hsd1.ca.comcast.net [24.7.16.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eager@eagerm.com) by homiemail-a94.g.dreamhost.com (Postfix) with ESMTPSA id 7437038A058; Thu, 22 May 2014 12:44:45 -0700 (PDT) Message-ID: <537E53AD.2070901@eagerm.com> Date: Thu, 22 May 2014 19:44:00 -0000 From: Michael Eager User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ajit Kumar Agarwal , Joel Brobecker CC: Michael Eager , "gdb-patches@sourceware.org" , Vinod Kathail , Vidhumouli Hunsigida , Nagaraju Mekala Subject: Re: [Patch, microblaze]: Add slr and shr regs and little-endian breakpoint References: <537BC5B9.10601@eagercon.com> <537C5A25.9000003@eagerm.com> <5821f144-e431-4bee-9cd7-33971b5512a3@BN1AFFO11FD019.protection.gbl> <20140521134544.GL22822@adacore.com> <6ece3192-e76c-42b1-8554-a69c67e29d52@BN1BFFO11FD024.protection.gbl> In-Reply-To: <6ece3192-e76c-42b1-8554-a69c67e29d52@BN1BFFO11FD024.protection.gbl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00569.txt.bz2 On 05/22/14 10:58, Ajit Kumar Agarwal wrote: > Thanks Joel for the review comments. Will make sure to consider your suggestions > when Submitting the new patches. Please don't top post. Please trim your responses so they don't contain multiple copies of the same text. > Based on the feedback, the updated patch is given below. > > Okay for the upstream? An OK would only be appropriate if you had write access to the repository. > [Patch, microblaze]: Add slr and shr regs > > This patch add the support of slr and shr regs and also solves the problem also? Is there another unmentioned problem? > related to process_g_packet where the buf_len > 2 * rsa->sizeof_g_packet > and throwing the Error that 'g' packet message reply is too long. This is > because the buf_len calculated in the init_remote_state function for > microblaze target is based On the sizeof_g_packet and remote_packet_size > and the memory_packet_config->size. The sizeof_g_packet is 236 because the > number of reg num is 59 and 2* sizeof_g_packet comes to 472 .With shr and > shl entry and the buf_len is 472. This does not match the greater than > conditional statement and works fine. Without shr and shl entry,the > sizeof_g_packets comes to 57*4 *2 = 456. This doesn't match the criteria > in the process_g_packet function leading to throwing of error message as > " 'g' packet message reply is too long". Please make the description of the problem reasonably succinct. A detailed analysis of how you identified the problem is not needed, especially when you mention the error message and the cause of the error multiple times. What is running on the target? If this a problem using the XMD gdbserver stub which is returning more registers than GDB expects? If that is the case, then say so. Otherwise, what is the cause of the mismatch between the gdb G packet and the target? > > ChangeLog: > 2014-05-20 Ajit Agarwal > > * gdb/gdbserver/Makefile.in (microblaze-linux.c): New rule. > > * gdb/microblaze-tdep.c (microblaze_register_names): Added > the rshr and rslr register names. > > * gdb/microblaze-tdep.h (microblaze_reg_num): Addition of > field MICROBLAZE_SLR_REGNUM and MICROBLAZE_SHR_REGNUM. > (microblaze_frame_cache): Change in the index of > register_offsets. > > * gdb/regformats/reg-microblaze.dat: New Register data file. > > Signed-off-by:Ajit Agarwal ajitkum@xilinx.com > > Thanks & Regards > Ajit > > -----Original Message----- > From: Joel Brobecker [mailto:brobecker@adacore.com] > Sent: Wednesday, May 21, 2014 7:16 PM > To: Ajit Kumar Agarwal > Cc: Michael Eager; Michael Eager; gdb-patches@sourceware.org; Vinod Kathail; Vidhumouli Hunsigida; Nagaraju Mekala > Subject: Re: [Patch, microblaze]: Add slr and shr regs and little-endian breakpoint > >> Here is the problem description. The problem is related to >> process_g_packet where the buf_len > 2 * rsa->sizeof_g_packet and >> throwing the Error that 'g' packet message reply is too long. This is >> because the buf_len calculated in the init_remote_state function for >> microblaze target is based On the sizeof_g_packet and >> remote_packet_size and the memory_packet_config->size. The >> sizeof_g_packet is 236 because the number of reg num is 59 and 2* >> sizeof_g_packet comes to 472 .With shr and shl entry and the buf_len >> is 472. This does not match the greater than conditional statement and >> works fine. Without shr and shl entry,the sizeof_g_packets comes to >> 57*4 *2 = 456. This doesn't match the criteria in the >> process_g_packet function leading to throwing of error message as " >> 'g' packet message reply is too long". >> >> This is happening when tar remote machine:1234 command is run in gdb. >> >>>>> These changes don't appear related. Split independent changes in >>>>> to separate patches. >> >> I will split the changes and send the separate patch with shr and shl >> reg changes and the little endian breakpoint support. > > Thanks, Ajit. FWIW, I agree with Michael. > > Also, when submitting the new patches, please include the description of the problem you are trying to solve in the revision log of your patch. Something like the description you gave above, for instance. > This makes archeology a lot easier for us. The good news when doing that is that submitting the patch could be as simple as "git send-email"-ing the patch; that's what I personally do for my own patches, and it's been a real time saver. > > -- > Joel > -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077