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] Modify altivec-regs.exp testcase for AIX
Date: Fri, 24 Feb 2023 15:37:21 +0000	[thread overview]
Message-ID: <9297ef8ccad3eba35f58f23e9abcd656daa65d0e.camel@de.ibm.com> (raw)
In-Reply-To: <CH2PR15MB354490AC92006B4D6AB52B16D6AB9@CH2PR15MB3544.namprd15.prod.outlook.com>

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

>Kindly review the patch in the previous email which changed
>the altivec-regs.exp so that AIX folks can also use this while
>in development. We are currently working on this feature.

This still needs at the very least more comments.  Note that
the existing comments in the test case specifically say that
this test *wants* to verify that VRs can be written before
they were ever used - which works on Linux but apparently
doesn't work on AIX.

Your patch changes this, but doesn't change those comments,
which makes the resulting test confusing to read.

Also, as a functional concern: you now execute the GDB
commands to modify vector register *after* the line
   x = ((vector unsigned int) vec_splat_u8 (-2));
was executed.

If the compiler chose to hold the value of x in a
register at this point, those GDB commands would
clobber the value of x, causing subsequent execution
to fail.

While this might happen to work with the executable
produced with the current compiler and/or settings,
this is not guaranteed.

I think it would be preferable to instead extend the
test case (when compiled on AIX only) by adding some
other instruction early in main, but before that
assignment to x, that touches a vector register,
and then perform the GDB register tests after that
new instruction and before the assignment to x.

Bye,
Ulrich


  reply	other threads:[~2023-02-24 15:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-14  7:38 Aditya Kamath1
2022-10-14  7:38 ` Aditya Kamath1
2022-10-14 12:47 ` Ulrich Weigand
2022-10-17  6:51   ` Aditya Kamath1
2022-10-17  6:51     ` Aditya Kamath1
2022-10-17  9:57     ` Ulrich Weigand
2022-10-17  9:57       ` Ulrich Weigand
2022-10-19  6:00       ` Aditya Kamath1
2022-10-19  6:00         ` Aditya Kamath1
2023-02-23 12:54         ` Aditya Kamath1
2023-02-24 15:37           ` Ulrich Weigand [this message]
2023-03-01 13:45             ` Aditya Kamath1
2023-03-03 15:50               ` Ulrich Weigand
2023-03-06  7:49                 ` Aditya Kamath1
2023-03-07  9:56                   ` Ulrich Weigand

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=9297ef8ccad3eba35f58f23e9abcd656daa65d0e.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).