public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Ajit Kumar Agarwal <ajit.kumar.agarwal@xilinx.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	       Michael Eager <eager@eagercon.com>,
	Vinod Kathail <vinodk@xilinx.com>,
	       Vidhumouli Hunsigida <vidhum@xilinx.com>,
	       Nagaraju Mekala <nmekala@xilinx.com>
Subject: Re: [Patch, microblaze]: Fix for remote G Packet message too long error for baremetal.
Date: Tue, 24 Jun 2014 12:46:00 -0000	[thread overview]
Message-ID: <53A97330.4080708@redhat.com> (raw)
In-Reply-To: <109c35c1-e2f6-430f-9235-c6c82a93daf1@BL2FFO11FD009.protection.gbl>

On 06/24/2014 01:31 PM, Ajit Kumar Agarwal wrote:

>>
>> The default is choosen to assume stack protect to make compatible with the handling of stack protect registers in XMD Debugger.
> 
>>> But you've already added the G packet size guess for that.
> 
> In this case is it correct to say 
> If (tdesc  == NULL)
>   tdesc = tdesc_microblaze; 
> 
> instead of tdesc_microblaze_with_stack_protect?

Yes.

> 
>>> -
>>> +  if (tdesc_data != NULL)
>>> +    {
>>> +      tdesc_use_registers (gdbarch, tdesc, tdesc_data);
>>> +      set_gdbarch_register_type (gdbarch, microblaze_register_type);
>>
>>>> Hmm, why is this set_gdbarch_register_type call necessary?
>>
>> /* Override tdesc_register_type to adjust the types of VFP
>>          registers for NEON.  */
>> This is done for arm target  to set the different type for VFP registers for Neon with Boolean flags is set before this call for VFP registers. In the microblaze target it's not required for special case of stack protect as 
> the microblaze_register_type always return builtin_int for these stack protect registers.
> 
> Right.

Actually, not right...  This comment doesn't really appear to be correct:

> In the microblaze target it's not required for special case of stack protect as
> the microblaze_register_type always return builtin_int for these stack protect registers.


static struct type *
microblaze_register_type (struct gdbarch *gdbarch, int regnum)
{
  if (regnum == MICROBLAZE_SP_REGNUM)
    return builtin_type (gdbarch)->builtin_data_ptr;

  if (regnum == MICROBLAZE_PC_REGNUM)
    return builtin_type (gdbarch)->builtin_func_ptr;

  return builtin_type (gdbarch)->builtin_int;
}

MICROBLAZE_SP_REGNUM and MICROBLAZE_PC_REGNUM clearly
aren't builtin_int...

Doesn't your patch change the output of "ptype $sp" and
"ptype $pc" ?

That points at something missing in the target description:

> +<!DOCTYPE feature SYSTEM "gdb-target.dtd">
> +<feature name="org.gnu.gdb.microblaze.core">
> +  <reg name="r1" bitsize="32"/>
...
> +  <reg name="rpc" bitsize="32"/>

AFAICS, SP is "r1", and PC is "rpc".  These should be marked with
type="data_ptr" and type="code_ptr" .

> 
>>>> As I mentioned before, please don't forget to document the new target features in the manual.
>>
>> Would you mind in explaining which manual need to be changed for the new target.
> 
>>> The GDB manual, gdb/doc/gdb.texinfo, describes all the standard XML target features.  See the "Standard Target Features" node, and add a new subsection for MicroBlaze.
> 
> Thanks !! I will add subsection for Microblaze target.

Thank you.

-- 
Pedro Alves

  reply	other threads:[~2014-06-24 12:46 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-12  8:56 Ajit Kumar Agarwal
2014-06-12 14:52 ` Michael Eager
2014-06-17 11:17 ` Pedro Alves
2014-06-18 11:06   ` Ajit Kumar Agarwal
2014-06-18 14:58     ` Michael Eager
2014-06-18 15:10     ` Pedro Alves
2014-06-18 15:30       ` Pedro Alves
2014-06-18 15:40       ` Ajit Kumar Agarwal
2014-06-18 15:54         ` Pedro Alves
2014-06-18 15:57           ` Ajit Kumar Agarwal
2014-06-18 19:56           ` Ajit Kumar Agarwal
2014-06-23 13:18             ` Pedro Alves
2014-06-23 19:36               ` Ajit Kumar Agarwal
2014-06-24  9:13                 ` Pedro Alves
2014-06-24 10:28                   ` Ajit Kumar Agarwal
2014-06-24 12:06                     ` Pedro Alves
2014-06-24 12:31                       ` Ajit Kumar Agarwal
2014-06-24 12:46                         ` Pedro Alves [this message]
2014-06-24 13:27                           ` Ajit Kumar Agarwal
2014-06-30 10:32                           ` Ajit Kumar Agarwal
2014-06-30 10:55                             ` Pedro Alves
2014-06-30 11:13                               ` Ajit Kumar Agarwal
2014-06-30 11:23                                 ` Pedro Alves
2014-06-30 16:29                                   ` Ajit Kumar Agarwal
2014-07-01 19:36                                   ` Ajit Kumar Agarwal
2014-07-20 12:57                                     ` Michael Eager
2014-06-30 14:47                             ` Michael Eager
2014-07-01 16:07                               ` Ajit Kumar Agarwal
2014-07-01 16:46                                 ` Michael Eager
2014-07-02 10:40                                   ` Ajit Kumar Agarwal
2014-06-24 14:11                       ` Michael Eager
2014-06-25 13:00                         ` Ajit Kumar Agarwal
2014-06-25 14:09                         ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53A97330.4080708@redhat.com \
    --to=palves@redhat.com \
    --cc=ajit.kumar.agarwal@xilinx.com \
    --cc=eager@eagercon.com \
    --cc=gdb-patches@sourceware.org \
    --cc=nmekala@xilinx.com \
    --cc=vidhum@xilinx.com \
    --cc=vinodk@xilinx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).