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, 3 Mar 2023 15:50:57 +0000	[thread overview]
Message-ID: <aac264442b8f051f7fe01d56cd4e3d8c70caa243.camel@de.ibm.com> (raw)
In-Reply-To: <CH2PR15MB35448D621C1FBDE1AD65268CD6AD9@CH2PR15MB3544.namprd15.prod.outlook.com>

Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:
>>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.
>
>So I do not have the knowledge to do that. I had seen the align-c
>test case which uses a tcl script and can do the same. However
>in .exp file how can we do it? Do you have an example which I
>can look into and learn how to does it, anything different also
>is fine. Kindly let me know. It will be of help to me,
>to contribute the same. 

The test case source file currently looks like this:

int
main ()
{
  vector unsigned int y;
  vector unsigned int x;
  vector unsigned int z;
  int a;

  /* This line may look unnecessary but we do need it, because we want to
     have a line to do a next over (so that gdb refetches the registers)
     and we don't want the code to change any vector registers.
     The splat operations below modify the VRs,i
     so we don't want to execute them yet.  */
  a = 9;
  x = ((vector unsigned int) vec_splat_u8 (-2));
  y = ((vector unsigned int) vec_splat_u8 (1));


I was thinking of simply modifying it along those lines:

int
main ()
{
  vector unsigned int y;
  vector unsigned int x;
  vector unsigned int z;
  int a;

#ifdef _AIX
  /* On AIX, the debugger cannot access vector registers before they
     are first used by the inferior.  Perform such an access here.  */
  x = ((vector unsigned int) vec_splat_u8 (0));
#endif

  /* This line may look unnecessary but we do need it, because we want to
     have a line to do a next over (so that gdb refetches the registers)
     and we don't want the code to change any vector registers.
     The splat operations below modify the VRs,i
     so we don't want to execute them yet.  */
  a = 9;  /* start here */
  x = ((vector unsigned int) vec_splat_u8 (-2));
  y = ((vector unsigned int) vec_splat_u8 (1));


And then, in the .exp file, instead of just doing a runto_main,
set a breakpoint on the /* start here */ line, and continue
until that is hit.  Something along the lines of:

    gdb_breakpoint [gdb_get_line_number "start here"]
    gdb_continue_to_breakpoint "start here"

(You can look at many other test cases as examples.)

On non-AIX platforms, this will have no actual effect,
as the /* start here */ line is still the first line
in the main routine.  But on AIX, it will have the expected
effect that we first touch a vector register, and then do
exactly the same test sequence as elsewhere.


Bye,
Ulrich


  reply	other threads:[~2023-03-03 15:51 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
2023-03-01 13:45             ` Aditya Kamath1
2023-03-03 15:50               ` Ulrich Weigand [this message]
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=aac264442b8f051f7fe01d56cd4e3d8c70caa243.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).