From: "Aktemur, Baris" <TankutBaris.Aktemur@amd.com>
To: "srinath.parvathaneni@arm.com" <srinath.parvathaneni@arm.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Cc: "guinevere@redhat.com" <guinevere@redhat.com>,
"thiago.bauermann@linaro.org" <thiago.bauermann@linaro.org>,
"luis.machado.foss@gmail.com" <luis.machado.foss@gmail.com>,
"Ezra.Sitorus@arm.com" <Ezra.Sitorus@arm.com>
Subject: RE: [PATCH v1] gdb: Fix assignment to TYPE_CODE_FLAGS registers
Date: Mon, 13 Jul 2026 13:37:57 +0000 [thread overview]
Message-ID: <PH7PR12MB6466385ECBC4BF7126828EE4F8FA2@PH7PR12MB6466.namprd12.prod.outlook.com> (raw)
In-Reply-To: <20260713091126.2914903-1-srinath.parvathaneni@arm.com>
AMD General
On Monday, July 13, 2026 11:11 AM, srinath.parvathaneni@arm.com wrote:
> From: Srinath Parvathaneni <srinath.parvathaneni@arm.com>
>
> GDB reports "Invalid cast" when assigning small integer literals (32-bit) to
> 64-bit TYPE_CODE_FLAGS registers. For example, with the existing upstream FPMR
> register, set $fpmr = 0x777777777 succeeds, whereas set $fpmr = 0x77 fails with
> "Invalid cast" and this patch fixes the issue but makes changes to a generic
> function value_cast in gdb/valops.c.
>
> * testsuite/gdb.arch/aarch64-fpmr.exp : Add "set $fpmr" test.
> * gdb/valops.c (value_cast): Add TYPE_CODE_FLAGS condition to integer
> assignment.
>
> Regression tested on aarch64-none-linux-gnu with no regressions.
>
> Ok for GDB master?
>
> Regards,
> Srinath
> ---
> gdb/testsuite/gdb.arch/aarch64-fpmr.exp | 6 ++++++
> gdb/valops.c | 2 +-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/gdb/testsuite/gdb.arch/aarch64-fpmr.exp b/gdb/testsuite/gdb.arch/aarch64-
> fpmr.exp
> index 72fd977fc67..2eee10fe924 100644
> --- a/gdb/testsuite/gdb.arch/aarch64-fpmr.exp
> +++ b/gdb/testsuite/gdb.arch/aarch64-fpmr.exp
> @@ -97,3 +97,9 @@ gdb_test_multiple "set \$fpmr=0x3f007f4008" "" {
> pass "Write to FPMR from GDB"
> }
> }
> +
> +gdb_test_multiple "set \$fpmr=0x1255C041" "" {
> + -re ".*\r\n.*\[ F8S1=E4M3 F8S2=E5M2 F8D=E4M3 OSM=MaxNormal OSC=MaxNormal
It should be possible to remove ".*\r\n.*" from the beginning of the regexp.
Is there a specific reason gdb_test_multiple was used instead of a simpler gdb_test?
If gdb_test_multiple is necessary for some reason, I'd also suggest adding -wrap to avoid
leaving unmatched contents in the buffer.
Regards,
-Baris
> LSCALE=85 NSCALE=18 LSCALE2=0 \]" {
> + pass "Write 32-bit value to 64-bit register FPMR from GDB"
> + }
> +}
> diff --git a/gdb/valops.c b/gdb/valops.c
> index ab6fd5079e1..170311dc63c 100644
> --- a/gdb/valops.c
> +++ b/gdb/valops.c
> @@ -557,7 +557,7 @@ value_cast (struct type *type, struct value *arg2)
> return value_from_longest (to_type, value_as_long (arg2));
> }
> else if ((code1 == TYPE_CODE_INT || code1 == TYPE_CODE_ENUM
> - || code1 == TYPE_CODE_RANGE)
> + || code1 == TYPE_CODE_RANGE || code1 == TYPE_CODE_FLAGS)
> && (scalar || code2 == TYPE_CODE_PTR
> || code2 == TYPE_CODE_MEMBERPTR))
> {
> --
> 2.43.0
prev parent reply other threads:[~2026-07-13 13:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-13 9:11 srinath.parvathaneni
2026-07-13 12:26 ` Simon Marchi
2026-07-13 13:37 ` Aktemur, Baris [this message]
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=PH7PR12MB6466385ECBC4BF7126828EE4F8FA2@PH7PR12MB6466.namprd12.prod.outlook.com \
--to=tankutbaris.aktemur@amd.com \
--cc=Ezra.Sitorus@arm.com \
--cc=gdb-patches@sourceware.org \
--cc=guinevere@redhat.com \
--cc=luis.machado.foss@gmail.com \
--cc=srinath.parvathaneni@arm.com \
--cc=thiago.bauermann@linaro.org \
/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