public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
To: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	Aditya Kamath1 <Aditya.Kamath1@ibm.com>,
	"simark@simark.ca" <simark@simark.ca>
Cc: Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>
Subject: Re: [PATCH] Enable vector instruction debugging for AIX
Date: Tue, 7 Mar 2023 10:25:54 +0000	[thread overview]
Message-ID: <300eb480053b4c27b868d23196058273758320b1.camel@de.ibm.com> (raw)
In-Reply-To: <CH2PR15MB3544D484ACE103AAC5299A1ED6B69@CH2PR15MB3544.namprd15.prod.outlook.com>

Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>So I connected with my seniors on this. So AIX folks are using 7.1 now. 
>So I have changed this to minimum 7.x.. Kindly see it in this patch. 
>For those who are below 7.1, we are not supporting. 

OK, this makes sense to me.  But it looks like you've added this
to the wrong section now, see below.

>>Fix coding style ({ should be indented).
>This is done. I have eliminated all RHS space and aligned the flower brackets wherever I saw it was not aligned.

Unfortunately it seems you changed many of these
in the wrong direction now.  GNU coding style is
to indent the { by two spaces, and then indent the
block inside by *another* two spaces:

  if (condition)
    {
      /* code */
    }

Also, the patch still introduces various instances of
8 spaces (that should be tabs), and whitespace at the
end of the line (which should be removed).


>@@ -938,6 +938,9 @@ info sources
> 
> ARM Symbian			arm*-*-symbianelf*
> 
>+GDB no longer supports AIX 4.x, AIX 5.x and AIX 6.x.  The minimum supported
>+AIX version is now AIX 7.1.
>+

You've added this under the GDB 11 news section, which is wrong.

You should instead add a new section 
  * Removed targets and native configurations
in the topmost 
  *** Changes since GDB 13
section.

>+  __vmx_context_t vmx;
>+  if (__power_vmx() && (flags & PTHDB_FLAG_REGS))
>+  {

Wrong indentation.

>+  /* vsx registers.  */
>+  __vsx_context_t vsx;
>+  if (__power_vsx() && (flags & PTHDB_FLAG_REGS))
>+  {

Likewise.

>+  /* vector registers.  */
>+  if (__power_vmx() && (flags & PTHDB_FLAG_REGS))
>+  {

Likewise.

>+  /* vsx registers.  */
>+  if (__power_vsx() && (flags & PTHDB_FLAG_REGS))
>+  {

Likewise.

>+  /* Fill altivec-registers.  */
>+
>+  if (__power_vmx())
>+  {

Likewise throughout the block

>+    memset(&vmx, 0, sizeof(__vmx_context_t));
>+    if (data->arch64)

Why is this check necessary, and what happens on 32-bit targets?

>+  /* Fill vsx registers. */
>+
>+  if (__power_vsx())
>+  {
>+    memset(&vsx, 0, sizeof(__vsx_context_t));
>+    if (data->arch64)

Same question, also same indentation issues.

>+    /* Vector registers.  */
>+    if (tdep->ppc_vr0_regnum != -1 && tdep->ppc_vrsave_regnum != -1
>+	&& (regno == -1 || (regno >= tdep->ppc_vr0_regnum
>+	&& regno <= tdep->ppc_vrsave_regnum)))
>+    {

Also indentation issues throughout the block.

>+    /* VSX registers.  */
>+    if (tdep->ppc_vsr0_upper_regnum != -1 && (regno == -1
>+	|| (regno >=tdep->ppc_vsr0_upper_regnum)))

You've now removed the upper limit completely.  I think this needs an 
  && regno < tdep->ppc_vsr0_upper_regnum + ppc_num_vshrs

>+  memset(&vsx, 0, sizeof(__vsx_context_t));
>+  if (__power_vsx() && thrd_i > 0)
>+  {

Indentation.

>+  memset(&vmx, 0, sizeof(__vmx_context_t));
>+  if (__power_vmx() && thrd_i > 0)
>+  {

Likewise.

>+  memset(&vmx, 0, sizeof(__vmx_context_t));
>+  if (__power_vmx() && thrd_i > 0)
>+  {

Likewise.

>+  memset(&vsx, 0, sizeof(__vsx_context_t));
>+  if (__power_vsx() && thrd_i > 0)
>+  {

Likewise.

>+  /* Alti-vec register.  */
>+  if (altivec_register_p (gdbarch, regno))
>+  {
>+    fetch_altivec_registers_aix (regcache);
>+    return;
>+  }
>+
>+  /* VSX register.  */
>+  if (vsx_register_p (gdbarch, regno))
>+  {
>+    fetch_vsx_registers_aix (regcache);
>+    return;
>+  }

Likewise.

>+  if (altivec_register_p (gdbarch, regno))
>+  {
>+    store_altivec_register_aix (regcache, regno);
>+    return;
>+  }
>+
>+  if (vsx_register_p (gdbarch, regno))
>+  {
>+    store_vsx_register_aix (regcache, regno);
>+    return;
>+  }

Likewise.

>+const struct target_desc *
>+rs6000_nat_target::read_description ()
>+{
>+   if (ARCH64())
>+   {
>+     if (__power_vsx ())
>+       return tdesc_powerpc_vsx64;
>+     else if (__power_vmx ())
>+       return tdesc_powerpc_altivec64;
>+   }
>+   else
>+   {
>+     if (__power_vsx ())
>+       return tdesc_powerpc_vsx32;
>+     else if (__power_vmx ())
>+       return tdesc_powerpc_altivec32;
>+   }
>+   return NULL;
>+}

Likewise.

>+  if (regnum == -1)
>+  {

Likewise.

>+  if (regnum == -1)
>+  {

Likewise.

>+  if (regnum == -1)
>+  {

Likewise.

>+  if (regnum == -1)
>+  {

Likewise.

Bye,
Ulrich


  reply	other threads:[~2023-03-07 10:25 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-13 10:52 Aditya Kamath1
2022-10-13 10:52 ` Aditya Kamath1
2022-10-14 12:41 ` Ulrich Weigand
2022-10-28 10:35   ` Aditya Kamath1
2022-10-28 12:39     ` Ulrich Weigand
2022-11-14 16:26       ` Aditya Kamath1
2022-11-15 19:03         ` Ulrich Weigand
2023-02-23 12:49           ` Aditya Kamath1
2023-02-24 15:26             ` Ulrich Weigand
2023-03-01 12:34               ` Aditya Kamath1
2023-03-03 14:59                 ` Ulrich Weigand
2023-03-06 13:45                   ` Aditya Kamath1
2023-03-07 10:25                     ` Ulrich Weigand [this message]
2023-03-07 12:13                       ` Aditya Kamath1
2023-03-07 12:55                         ` Ulrich Weigand
2023-03-07 13:24                           ` Aditya Kamath1
2023-03-07 15:53                             ` Ulrich Weigand
2023-03-09  2:21                               ` Aditya Kamath1

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=300eb480053b4c27b868d23196058273758320b1.camel@de.ibm.com \
    --to=ulrich.weigand@de.ibm.com \
    --cc=Aditya.Kamath1@ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=sangamesh.swamy@in.ibm.com \
    --cc=simark@simark.ca \
    /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).