From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3382 invoked by alias); 23 May 2014 07:35:33 -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 3373 invoked by uid 89); 23 May 2014 07:35:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout22.012.net.il Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 23 May 2014 07:35:31 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0N6000D00NJZAO00@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Fri, 23 May 2014 10:35:28 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N6000CXLNR3XB70@a-mtaout22.012.net.il>; Fri, 23 May 2014 10:35:28 +0300 (IDT) Date: Fri, 23 May 2014 07:35:00 -0000 From: Eli Zaretskii Subject: Re: [Patch, microblaze]: Add slr and shr regs and little-endian breakpoint In-reply-to: <537EF6EF.5060901@eagercon.com> To: Michael Eager Cc: ajit.kumar.agarwal@xilinx.com, brobecker@adacore.com, gdb-patches@sourceware.org, vinodk@xilinx.com, vidhum@xilinx.com, nmekala@xilinx.com Reply-to: Eli Zaretskii Message-id: <83oaypkkvk.fsf@gnu.org> 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> <537EF6EF.5060901@eagercon.com> X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00581.txt.bz2 > Date: Fri, 23 May 2014 00:21:19 -0700 > From: Michael Eager > CC: ajit.kumar.agarwal@xilinx.com, brobecker@adacore.com, > gdb-patches@sourceware.org, vinodk@xilinx.com, vidhum@xilinx.com, > nmekala@xilinx.com > > >>> 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. The numbers don't match, so that inequality seems to be fragile. That's my understanding. > > 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. Well, perhaps no Ajit understand better what we didn't understand in his original description, and will hopefully follow up.