Re: [Patch, microblaze]: Fix for remote G Packet message too long error for baremetal.

[Pedro Alves <palves@redhat.com>]

On 06/18/2014 04:39 PM, Ajit Kumar Agarwal wrote:

> The info registers against such a  stub( where the design does not
> have stack-protect registers) shows the registers $rshr and $rslr but
> it shows as <unavailable>.  Is the display of $rshr and $rslr happening 
> because of this second guess with -2 case? 

Yes, because you're guessing a target description that includes
the registers.

Is it inappropriate to have the second guess with -2 case?

It is, but you're guessing the wrong description...

In addition to tdesc_microblaze_with_stack_protect, create _another_
description that does _not_ xi:include the stack protect feature, and
register the guess with that:

microblaze_register_g_packet_guesses (struct gdbarch *gdbarch)
{
  register_remote_g_packet_guess (gdbarch,
				  MICROBLAZE_NUM_REGS,
                                  tdesc_microblaze_with_stack_protect);

  register_remote_g_packet_guess (gdbarch,
                                  MICROBLAZE_NUM_REGS - 2,
                                  tdesc_microblaze);
}

I'd add a MICROBLAZE_NUM_CORE_REGS value to the registers enum.  Then
instead of that magic " - 2", you could write:

{
  register_remote_g_packet_guess (gdbarch,
				  MICROBLAZE_NUM_CORE_REGS,
                                  tdesc_microblaze);

  register_remote_g_packet_guess (gdbarch,
                                  MICROBLAZE_NUM_REGS,
                                  tdesc_microblaze_with_stack_protect);

-- 
Pedro Alves