From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21647 invoked by alias); 23 May 2014 07:21:25 -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 21633 invoked by uid 89); 23 May 2014 07:21:24 -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: qmta13.emeryville.ca.mail.comcast.net Received: from qmta13.emeryville.ca.mail.comcast.net (HELO qmta13.emeryville.ca.mail.comcast.net) (76.96.27.243) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 23 May 2014 07:21:22 +0000 Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta13.emeryville.ca.mail.comcast.net with comcast id 5KJg1o0030lTkoCADKMMjS; Fri, 23 May 2014 07:21:21 +0000 Received: from redwood.eagercon.com ([24.7.16.38]) by omta04.emeryville.ca.mail.comcast.net with comcast id 5KMK1o00U0pGQcg8QKMLtq; Fri, 23 May 2014 07:21:20 +0000 Message-ID: <537EF6EF.5060901@eagercon.com> Date: Fri, 23 May 2014 07:21: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: Eli Zaretskii , Michael Eager CC: ajit.kumar.agarwal@xilinx.com, brobecker@adacore.com, gdb-patches@sourceware.org, vinodk@xilinx.com, vidhum@xilinx.com, nmekala@xilinx.com 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> <537E53AD.2070901@eagerm.com> <83y4xtkpf2.fsf@gnu.org> In-Reply-To: <83y4xtkpf2.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2014-05/txt/msg00579.txt.bz2 On 05/22/14 22:57, Eli Zaretskii wrote: >> Date: Thu, 22 May 2014 12:44:45 -0700 >> From: Michael Eager >> CC: Michael Eager , "gdb-patches@sourceware.org" , Vinod Kathail , Vidhumouli Hunsigida , Nagaraju Mekala >> >>> 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. > > An OK is appropriate even if the OP doesn't have write access. An OK > just means the patch is approved for committing. > >>> This patch add the support of slr and shr regs and also solves the problem >> >> also? Is there another unmentioned problem? > > There is indeed another problem, but it _is_ mentioned: the missing > support for slr and shr registers. > >>> 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. > > I see no reason to object to detailed descriptions like the one above > from the POV of their length. They don't hurt, and aren't terribly > long to begin with. Eli -- The problem with this description is that it doesn't describe the actual problem, but more describes the debugging process. Describing the if statement which tests the packet length doesn't tell what caused it to be incorrect. >> 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? > > If you want to suggest a rewording, it is much better IME to just show > precisely your suggestion. After all, for most of us here (present > parties included) English is not our first language, maybe not even > the second. I'm happy to suggest better wording, but at the moment I have no more than a guess what the root cause of the problem is. Ajit says my guess is wrong, and he didn't respond to my questions about what is running on the target which does cause the packet length mismatch. -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077