This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]