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: Fri, 3 Mar 2023 14:59:22 +0000	[thread overview]
Message-ID: <cd3122b9d075c0a7e27404c14ee35a39b80277f2.camel@de.ibm.com> (raw)
In-Reply-To: <CH2PR15MB3544CCE02934081D8C720585D6AD9@CH2PR15MB3544.namprd15.prod.outlook.com>

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

>Please find attached the patch. {See: 0001-Enable-vector-instruction-debugging-for-AIX.patch}.

This should be nearly ready to commit, I've just found a
few minor issues - see below.

Also, please provide commit message.

>--- a/gdb/NEWS
>+++ b/gdb/NEWS
>@@ -3,6 +3,8 @@
> 
> *** Changes since GDB 13
> 
>+* AIX now needs to be of version 5.2 or higher to install GDB.
>+
> * Multi-target feature configuration
> 
>   GDB now supports the individual configuration of remote targets' feature

I think these are usually under a separate section, something like:

 * Removed targets and native configurations

 GDB no longer supports AIX 4.x and AIX 5.1.  The minimum supported
 AIX version is now AIX 5.2.

As a separate note, I see that even AIX 5.2 itself has been out of
support for over 13 years now, so I'm wondering how much sense it
makes to still claim support for this in GDB.  If we're already
deprecating old versions, maybe it would be better to set the
minimum supported version at 6.1 or even 7.1 at this point? 

>@@ -7606,10 +7608,10 @@ the possible architectures.
> 
> Windows 95, x86 Windows NT			i[345]86-*-cygwin32
> M68K NetBSD					m68k-*-netbsd*
>-PowerPC AIX 4.x					powerpc-*-aix*
>+PowerPC AIX 5.2 or higher			powerpc-*-aix*
> PowerPC MacOS					powerpc-*-macos*
> PowerPC Windows NT				powerpcle-*-cygwin32
>-RS/6000 AIX 4.x					rs6000-*-aix4*
>+RS/6000 AIX 5.2 or higher			rs6000-*-aix4*

This describes what was added in GDB 4.18 - I don't think this
section should be retroactively modified.
 
>+static void 
>+supply_altivec_regs (struct regcache *regcache, __vmx_context_t vmx)
>+{ 
>+  ppc_gdbarch_tdep *tdep
>+    = gdbarch_tdep<ppc_gdbarch_tdep> (regcache->arch ());
>+  int regno; 
>+  int num_of_vrregs = tdep->ppc_vrsave_regnum - tdep->ppc_vr0_regnum + 1;
>+  for (regno = 0; regno < num_of_vrregs; regno++)
>+     regcache->raw_supply (tdep->ppc_vr0_regnum + regno, 
>+			   &(vmx.__vr[regno]));

Now that you've taken VRSAVE and VSCR separately, this loop now
only needs to execute 32 times, but you still do it 34 times.
I think you should just use ppc_num_vrs instead of this
num_of_vrregs you compute here.

>+  regcache->raw_supply (tdep->ppc_vrsave_regnum, &(vmx.__vrsave));
>+  regcache->raw_supply (tdep->ppc_vrsave_regnum - 1, &(vmx.__vscr));

>+  /* vector registers.  */
>+  if (tdep->ppc_vr0_regnum != -1)
>+    {
>+      int ret = 0;
>+      int num_of_vrregs = tdep->ppc_vrsave_regnum - tdep->ppc_vr0_regnum + 1;
>+      __vmx_context_t vmx;
>+      if (data->arch64)
>+	ret = ptrace64aix (PTT_READ_VEC, tid, (long long) &vmx, 0, 0);
>+      else
>+	ret = ptrace32 (PTT_READ_VEC, tid, (uintptr_t) &vmx, 0, 0);
>+      if (ret < 0)
>+	memset(&vmx, 0, sizeof(__vmx_context_t));
>+      for (i = 0; i < num_of_vrregs; i++)
>+	regcache->raw_supply (tdep->ppc_vr0_regnum + i, &(vmx.__vr[i]));

Same problem here.

>+      regcache->raw_supply (tdep->ppc_vrsave_regnum, &(vmx.__vrsave));
>+      regcache->raw_supply (tdep->ppc_vrsave_regnum - 1, &(vmx.__vscr));

>+static void
>+fill_altivec (const struct regcache *regcache, __vmx_context_t *vmx)
>+{
>+  struct gdbarch *gdbarch = regcache->arch ();
>+  ppc_gdbarch_tdep *tdep = gdbarch_tdep<ppc_gdbarch_tdep> (gdbarch);
>+  int num_of_vrregs = tdep->ppc_vrsave_regnum - tdep->ppc_vr0_regnum + 1;
>+  int regno;
>+
>+  for (regno = 0; regno < num_of_vrregs; regno++)
>+    if (REG_VALID == regcache->get_register_status (tdep->ppc_vr0_regnum + regno))
>+      regcache->raw_collect (tdep->ppc_vr0_regnum + regno,
>+                                 &(vmx->__vr[regno]));

And here.

>+  if (REG_VALID == regcache->get_register_status (tdep->ppc_vrsave_regnum))
>+  { 
>+    regcache->raw_collect (tdep->ppc_vrsave_regnum, &(vmx->__vrsave));
>+    regcache->raw_collect (tdep->ppc_vrsave_regnum - 1, &(vmx->__vscr));

You should separately check VSCR for REG_VALID.

>+  int num_of_vrregs = tdep->ppc_vrsave_regnum - tdep->ppc_vr0_regnum + 1;

Same problem here.
 
>+      if (REG_VALID == regcache->get_register_status (tdep->ppc_vrsave_regnum))
>+      {
>+	ctx.vmx.__vrsave = vmx.__vrsave;
>+	ctx.vmx.__vscr = vmx.__vscr;

Also should do a separate REG_VALID check.

>@@ -1766,6 +1979,56 @@ store_regs_kernel_thread (const struct regcache *regcache, int regno,
>+    /* vmx registers.  */
Should be VSX ?
>+    if (tdep->ppc_vsr0_upper_regnum != -1  && tdep->ppc_vrsave_regnum != -1
>+       && (regno == -1 || (regno >= tdep->ppc_vsr0_upper_regnum
>+       && regno <= tdep->ppc_vrsave_regnum))) 

The regno comparison looks inconsistent (lower bound VSX; upper bound VMX).

>+supply_vrregset_aix (struct regcache *regcache, __vmx_context_t *vmx)
>+{
>+  int i;
>+  struct gdbarch *gdbarch = regcache->arch ();
>+  ppc_gdbarch_tdep *tdep = gdbarch_tdep<ppc_gdbarch_tdep> (gdbarch);
>+  int num_of_vrregs = tdep->ppc_vrsave_regnum - tdep->ppc_vr0_regnum + 1;
>+
>+  for (i = 0; i < num_of_vrregs; i++)
>+    regcache->raw_supply (tdep->ppc_vr0_regnum + i,
>+                                    &(vmx->__vr[i]));

Same loop count problem here.

>+  regcache->raw_supply (tdep->ppc_vrsave_regnum, &(vmx->__vrsave));
>+  regcache->raw_supply (tdep->ppc_vrsave_regnum - 1, &(vmx->__vscr));

>+  /*Alti-vec register.  */
Missing space
>+  /*VSX register.  */
Here as well.
 
>+  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;
>+  }
Fix coding style ({ should be indented).


Bye,
Ulrich


  reply	other threads:[~2023-03-03 14:59 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 [this message]
2023-03-06 13:45                   ` Aditya Kamath1
2023-03-07 10:25                     ` Ulrich Weigand
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=cd3122b9d075c0a7e27404c14ee35a39b80277f2.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).