From: Tankut Baris Aktemur <tankutbaris.aktemur@amd.com>
To: <gdb-patches@sourceware.org>
Cc: <keiths@redhat.com>, <tom@tromey.com>
Subject: [PATCH 2/2] gdb: preserve lhs type's address spaces/classes in check_typedef
Date: Mon, 27 Jul 2026 09:20:01 +0000 [thread overview]
Message-ID: <20260727092001.1683349-2-tankutbaris.aktemur@amd.com> (raw)
In-Reply-To: <20260727092001.1683349-1-tankutbaris.aktemur@amd.com>
In commit 92fdad7 "gdb: convert type instance flags to bitfields",
`operator|=` of type_instance_flags required the address space and
address class values of left-hand-side to be zero. This introduced
the following bug (thanks to Keith Seitz for reporting it at
https://inbox.sourceware.org/gdb-patches/053e90c0-53f0-4748-9d27-0237b9f21221@redhat.com/T/#u):
typedef int myint;
(gdb) ptype (@code myint) 3
../../src/gdb/gdbtypes.h:127: internal-error: operator|=: Assertion
`harvard_aspace == 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0x5bb1d1 gdb_internal_backtrace_1
../../src/gdb/bt-utils.c:122
0x5bb210 _Z22gdb_internal_backtracev
../../src/gdb/bt-utils.c:173
0xdfbbaa internal_vproblem
../../src/gdb/utils.c:434
0xdfbf45 _Z15internal_verrorPKciS0_P13__va_list_tag
../../src/gdb/utils.c:514
0x162763f _Z18internal_error_locPKciS0_z
../../src/gdbsupport/errors.cc:57
0x87e8e6 _ZN19type_instance_flagsoRERKS_
../../src/gdb/gdbtypes.h:127
0x875d71 _Z13check_typedefP4type
../../src/gdb/gdbtypes.c:3072
The |= operator is used in check_typedef as follows:
/* Preserve the instance flags as we traverse down the typedef chain.
Handling address spaces/classes is nasty, what do we do if there's a
conflict?
E.g., what if an outer typedef marks the type as class_1 and an inner
typedef marks the type as class_2?
This is the wrong place to do such error checking. We leave it to
the code that created the typedef in the first place to flag the
error. We just pick the outer address space (akin to letting the
outer cast in a chain of casting win), instead of assuming
"it can't happen". */
{
type_instance_flags new_instance_flags = type->instance_flags ();
new_instance_flags.harvard_aspace = HARVARD_ASPACE_NONE;
new_instance_flags.address_class = 0;
instance_flags |= new_instance_flags;
}
So, the assertion in operator|= was applied on the wrong operand. The
outer type, which is the left-hand-side in this case, should preserve
its values whereas the right-hand-side should have 0 as its address
space and address class values.
Fix the bug by updating the assertion.
Furthermore, rename operator|= to "merge". Type instance flags are no
longer stored as a bitmask value, but rather as a struct. Having an
operator like |= gives the wrong impression that we are doing a
bitmask OR. Using a method makes the intention clearer.
Include a regression test.
---
gdb/gdbtypes.c | 2 +-
gdb/gdbtypes.h | 14 +++++++-------
gdb/testsuite/gdb.cp/typedef-operator.exp | 3 +++
3 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c
index ad401872941..66c00da389a 100644
--- a/gdb/gdbtypes.c
+++ b/gdb/gdbtypes.c
@@ -3065,7 +3065,7 @@ check_typedef (struct type *type)
new_instance_flags.harvard_aspace = HARVARD_ASPACE_NONE;
new_instance_flags.address_class = 0;
- instance_flags |= new_instance_flags;
+ instance_flags.merge (new_instance_flags);
}
}
diff --git a/gdb/gdbtypes.h b/gdb/gdbtypes.h
index eda09641248..f8d7ed5ab91 100644
--- a/gdb/gdbtypes.h
+++ b/gdb/gdbtypes.h
@@ -119,21 +119,21 @@ struct type_instance_flags
return !(*this == other);
}
- type_instance_flags &operator|= (const type_instance_flags &other)
+ /* Merge OTHER flags to THIS, except address spaces and address
+ classes. Require OTHER's address space and address class to be
+ zero, and preserve the address space and address class values of
+ THIS. */
+ void merge (const type_instance_flags &other)
{
is_const = is_const || other.is_const;
is_volatile = is_volatile || other.is_volatile;
- gdb_assert (harvard_aspace == 0);
- harvard_aspace = other.harvard_aspace;
-
- gdb_assert (address_class == 0);
- address_class = other.address_class;
+ gdb_assert (other.harvard_aspace == HARVARD_ASPACE_NONE);
+ gdb_assert (other.address_class == 0);
is_nottext = is_nottext || other.is_nottext;
is_restrict = is_restrict || other.is_restrict;
is_atomic = is_atomic || other.is_atomic;
- return *this;
}
/* Constant type. If this is set, the corresponding type has a
diff --git a/gdb/testsuite/gdb.cp/typedef-operator.exp b/gdb/testsuite/gdb.cp/typedef-operator.exp
index 9513b3725dc..e03502769a4 100644
--- a/gdb/testsuite/gdb.cp/typedef-operator.exp
+++ b/gdb/testsuite/gdb.cp/typedef-operator.exp
@@ -32,3 +32,6 @@ if {![runto_main]} {
}
gdb_test "p *v" " = 42" "test typedef"
+
+# Test that address spaces are preserved.
+gdb_test "ptype (@data D)u" "type = @data class C .*"
--
2.53.0
next prev parent reply other threads:[~2026-07-27 9:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-27 9:20 [PATCH 1/2] gdb: simplify code " Tankut Baris Aktemur
2026-07-27 9:20 ` Tankut Baris Aktemur [this message]
2026-07-29 17:27 ` Keith Seitz
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=20260727092001.1683349-2-tankutbaris.aktemur@amd.com \
--to=tankutbaris.aktemur@amd.com \
--cc=gdb-patches@sourceware.org \
--cc=keiths@redhat.com \
--cc=tom@tromey.com \
/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