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
next prev parent 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).