This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [Patch, microblaze]: Add slr and shr regs
- From: Michael Eager <eager at eagercon dot com>
- To: Ajit Kumar Agarwal <ajit dot kumar dot agarwal at xilinx dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Cc: Joel Brobecker <brobecker at adacore dot com>, Vinod Kathail <vinodk at xilinx dot com>, Vidhumouli Hunsigida <vidhum at xilinx dot com>, Nagaraju Mekala <nmekala at xilinx dot com>
- Date: Fri, 23 May 2014 00:34:32 -0700
- Subject: Re: [Patch, microblaze]: Add slr and shr regs
- Authentication-results: sourceware.org; auth=none
- References: <c6fe468a-5e02-430a-b34b-73de6bfd2b97 at BY2FFO11FD021 dot protection dot gbl>
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 <ajitkum@xilinx.com>
* 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