From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 956 invoked by alias); 23 May 2014 07:34:36 -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 936 invoked by uid 89); 23 May 2014 07:34:35 -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:34:34 +0000 Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta13.emeryville.ca.mail.comcast.net with comcast id 5KZM1o0011eYJf8ADKaZ3j; Fri, 23 May 2014 07:34:33 +0000 Received: from redwood.eagercon.com ([24.7.16.38]) by omta19.emeryville.ca.mail.comcast.net with comcast id 5KaY1o0060pGQcg01KaY6W; Fri, 23 May 2014 07:34:32 +0000 Message-ID: <537EFA08.1060309@eagercon.com> Date: Fri, 23 May 2014 07:34: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 , "gdb-patches@sourceware.org" CC: Joel Brobecker , Vinod Kathail , Vidhumouli Hunsigida , Nagaraju Mekala Subject: Re: [Patch, microblaze]: Add slr and shr regs References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2014-05/txt/msg00580.txt.bz2 On 05/22/14 23:53, Ajit Kumar Agarwal wrote: > Hello Michael: > > Based on the feedback, resubmitting the patch once again with all your replies and suggestions. > > [Patch, microblaze]: Add slr and shr regs > > This patch add the support of slr and shr regs and also solves the 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". > > 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 > > I am confused with your comments whereas it seems I have answered all queries(including yours) and incorporated your review comments. > Just to make sure I repeat, see below answers to your queries. > >>> Make sure you address my comments and incorporate my suggestions as well. > > I made sure that the description is not too long at the same time it gives the complete picture. Hope this addresses your comments. > >>>> I asked what is running on the target which is returning a different sized G packet. > > It is the gdbserver which is checking for the buf_len and 2* size_of_g_packet in process_g_packet function which is not matching > and returning with error mentioning that 'g' packet is too long. The G Packet initialization is done in init_remote_state function which > is all happening when tar remote machine:1234 command is used. I'm quite familiar with how G packets are handled. An explanation of this is not answering my questions. > Hope this clarifies as this error is nothing to do with what is running on target. On target the XMD is running. I asked you to start over and resubmit a patch, including Changelog, without the replies. At this point, I don't know what Changelog corresponds to the patch. I asked if XMD was connected to the target. You said it wasn't. Now you say that it is, and that gdbserver is running. This doesn't make sense to me, since if you are running gdbserver on the target, and it is built from the same sources, you will never get a G packet mismatch. Let's try this one more time: GDB is connected to something when you tell it to connect to the target with the "target remote" command. This is returning a different sized G packet. What is it that you are connecting to? > -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077