Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tankut Baris Aktemur <tankutbaris.aktemur@amd.com>
To: <gdb-patches@sourceware.org>
Cc: <keiths@redhat.com>, <tom@tromey.com>
Subject: [PATCH v2] gdb: prefer lhs type's address spaces/classes in check_typedef
Date: Thu, 30 Jul 2026 09:13:57 +0000	[thread overview]
Message-ID: <20260730091357.2528178-1-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 ();

        /* Treat code vs data spaces and address classes separately.  */
        if (instance_flags.harvard_aspace != HARVARD_ASPACE_NONE)
          new_instance_flags.harvard_aspace = HARVARD_ASPACE_NONE;
        if (instance_flags.address_class != 0)
          new_instance_flags.address_class = 0;

        instance_flags |= new_instance_flags;
      }

So, the assertion in operator|= was wrong.  The outer type, which is
the left-hand-side in this case, should preserve its values if they
are non-zero.  The right-hand-side values are used, if lhs values are
zero.  Fix the bug accordingly.

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                            | 12 +-----------
 gdb/gdbtypes.h                            | 15 ++++++++-------
 gdb/testsuite/gdb.cp/typedef-operator.exp |  3 +++
 3 files changed, 12 insertions(+), 18 deletions(-)

diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c
index 9098727959e..bf4cfe0250d 100644
--- a/gdb/gdbtypes.c
+++ b/gdb/gdbtypes.c
@@ -3060,17 +3060,7 @@ check_typedef (struct type *type)
 	 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 ();
-
-	/* Treat code vs data spaces and address classes separately.  */
-	if (instance_flags.harvard_aspace != HARVARD_ASPACE_NONE)
-	  new_instance_flags.harvard_aspace = HARVARD_ASPACE_NONE;
-	if (instance_flags.address_class != 0)
-	  new_instance_flags.address_class = 0;
-
-	instance_flags |= new_instance_flags;
-      }
+      instance_flags.merge (type->instance_flags ());
     }
 
   /* If this is a struct/class/union with no fields, then check
diff --git a/gdb/gdbtypes.h b/gdb/gdbtypes.h
index eda09641248..dd2d24fa8e2 100644
--- a/gdb/gdbtypes.h
+++ b/gdb/gdbtypes.h
@@ -119,21 +119,22 @@ struct type_instance_flags
     return !(*this == other);
   }
 
-  type_instance_flags &operator|= (const type_instance_flags &other)
+  /* Merge OTHER flags to THIS.  Address space and address class
+     values of THIS are preserved, if they are non-zero.  Otherwise,
+     OTHER's values are used.  */
+  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;
+    if (harvard_aspace == HARVARD_ASPACE_NONE)
+      harvard_aspace = other.harvard_aspace;
+    if (address_class == 0)
+      address_class = other.address_class;
 
     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


  parent reply	other threads:[~2026-07-30  9:15 UTC|newest]

Thread overview: 7+ 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 ` [PATCH 2/2] gdb: preserve lhs type's address spaces/classes " Tankut Baris Aktemur
2026-07-29 17:27 ` [PATCH 1/2] gdb: simplify code " Keith Seitz
2026-07-30  5:47   ` Aktemur, Baris
2026-07-30  9:13 ` Tankut Baris Aktemur [this message]
2026-07-30 18:12   ` [PATCH v2] gdb: prefer lhs type's address spaces/classes " Keith Seitz
2026-08-03  7:57     ` Aktemur, Baris

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=20260730091357.2528178-1-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