RE: [Patch, microblaze]: Add slr and shr regs

[Ajit Kumar Agarwal <ajit.kumar.agarwal@xilinx.com>]

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?

Here is the flow from GBD Client to XMD that's what is happening:

1. XMD connects to the hardware target through JTAG.
2. XMD Opens a GDB Server on the local host 1234.
3. GDB Client will connect to  the host:1234 through TCP, when the command "tar remote localhost:1234" is given.

Thanks & Regards
Ajit 


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077