From: Andrew Burgess <aburgess@redhat.com>
To: gdb-patches@sourceware.org
Cc: Andrew Burgess <aburgess@redhat.com>
Subject: [PATCH 6/6] gdb: use value::embedded_offset in check_pieced_synthetic_pointer
Date: Tue, 12 May 2026 11:07:27 +0100 [thread overview]
Message-ID: <51ce4ffad7667ef14f1d9bd4d7bf2746d410d183.1778579473.git.aburgess@redhat.com> (raw)
In-Reply-To: <cover.1778579473.git.aburgess@redhat.com>
This commit builds on the previous two commits. You should go and
read them both for context.
Looking at the users of value::bits_synthetic_pointer, all callers but
two are now passing either the offset of a field within the value, or
hard-coded zero as they want to ask about the entire value.
The two exceptions are in coerce_pieced_ref (in dwarf2/expr.c) and in
value_addr (in valops.c) where we still pass value::embedded_offset.
The problem is that some of the other callers, where we currently pass
just a field offset, might also have a non-zero embedded offset,
specifically, the call in cp_print_value_fields is in this category.
In cp_print_value_fields we are printing fields from a value which is
potentially a base class contained within an instance of a derived
class, this will be represented by a non-zero embedded_offset, which
is currently not taken into account.
Additionally, the two callers that currently pass the
value::embedded_offset don't scale the embedded offset from bytes to
bits.
The failure to scale from bytes to bits is interesting, I originally
tried to create some tests that exposed this, but constantly failed.
It turns out, that in both these locations, in all code paths that I
could find, the value::embedded_offset will always be zero. For
example in coerce_pieced_ref, a reference cannot be a base class, and
so we never expect to see a non-zero embedded_offset in this case.
Similarly, in value_addr, the use of value::bits_synthetic_pointer is
within a block that only applies to reference types, which means the
embedded_offset will be zero.
Now within check_pieced_synthetic_pointer we already add the
value::offset into the bit_offset which is passed in. Remember, after
the previous two commits, the incoming bit_offset is (almost) always
the offset of a field within the value. The almost here is the two
cases mentioned above.
I propose that within check_pieced_synthetic_pointer we should take
into account both value::offset and value::embedded_offset. Then the
two cases that currently pass value::embedded_offset can be changed to
just pass zero.
With this done, and the previous two commits, we now have a consistent
model. value::bits_synthetic_pointer expects the (bit) offset of a
field within the value to check. In many cases this will be zero
meaning we want to check from the start of the value, but in some
cases it can be non-zero.
Then within value::bits_synthetic_pointer implementations, like
check_pieced_synthetic_pointer, we will take the value::offset and
value::embedded_offset into account, remembering to scale them from
bytes to bits.
I have also changed indirect_pieced_value to also take the
embedded_offset into account. I have done this for consistency rather
than necessity. I believe that the embedded_offset will always be
zero within indirect_pieced_value. The indirect_pieced_value function
is only called from value_ind (in valops.c), and only operates on
TYPE_CODE_PTR types (checked for in indirect_pieced_value). As a
TYPE_CODE_PTR cannot be the base class for a derived type, then we
don't expect to ever see a TYPE_CODE_PTR value with a non-zero
embedded_offset. But, having indirect_pieced_value take the embedded
offset into account is simple enough, and future proofs the code.
The gdb.dwarf2/multi-piece-inherited-bitfield.exp test fails without
this patch, this exposes the case where the embedded_offset is
non-zero and we were previously failing to take this into account.
The gdb.dwarf2/multi-piece-primitive-field.exp test was something I
wrote while trying to exercise the coerce_pieced_ref code path some
more. It is an inheritance based version of the existing test, I was
wondering if this would result in a value with a non-zero
embedded_offset, but due to how the fields are extracted from the
aggregate prior to calling coerce_pieced_ref the embedded_offset is
always zero in this function.
---
gdb/dwarf2/expr.c | 9 +-
.../multi-piece-inherited-bitfield.c | 25 +++
.../multi-piece-inherited-bitfield.exp | 151 ++++++++++++++++++
.../multi-piece-primitive-field.exp | 62 ++++++-
gdb/valops.c | 3 +-
5 files changed, 243 insertions(+), 7 deletions(-)
create mode 100644 gdb/testsuite/gdb.dwarf2/multi-piece-inherited-bitfield.c
create mode 100644 gdb/testsuite/gdb.dwarf2/multi-piece-inherited-bitfield.exp
diff --git a/gdb/dwarf2/expr.c b/gdb/dwarf2/expr.c
index a554dd2c880..8b0de78887f 100644
--- a/gdb/dwarf2/expr.c
+++ b/gdb/dwarf2/expr.c
@@ -502,7 +502,8 @@ check_pieced_synthetic_pointer (const value *value, LONGEST bit_offset,
piece_closure *c = (piece_closure *) value->computed_closure ();
int i;
- bit_offset += TARGET_CHAR_BIT * value->offset ();
+ bit_offset += (TARGET_CHAR_BIT
+ * (value->offset () + value->embedded_offset ()));
if (value->bitsize ())
bit_offset += value->bitpos ();
@@ -548,7 +549,8 @@ indirect_pieced_value (value *value)
return NULL;
int bit_length = TARGET_CHAR_BIT * type->length ();
- LONGEST bit_offset = TARGET_CHAR_BIT * value->offset ();
+ LONGEST bit_offset
+ = (TARGET_CHAR_BIT * (value->offset () + value->embedded_offset ()));
if (value->bitsize ())
bit_offset += value->bitpos ();
@@ -612,8 +614,7 @@ coerce_pieced_ref (const value *value)
{
struct type *type = check_typedef (value->type ());
- if (value->bits_synthetic_pointer (value->embedded_offset (),
- TARGET_CHAR_BIT * type->length ()))
+ if (value->bits_synthetic_pointer (0, TARGET_CHAR_BIT * type->length ()))
{
const piece_closure *closure
= (piece_closure *) value->computed_closure ();
diff --git a/gdb/testsuite/gdb.dwarf2/multi-piece-inherited-bitfield.c b/gdb/testsuite/gdb.dwarf2/multi-piece-inherited-bitfield.c
new file mode 100644
index 00000000000..7ec6b26af49
--- /dev/null
+++ b/gdb/testsuite/gdb.dwarf2/multi-piece-inherited-bitfield.c
@@ -0,0 +1,25 @@
+/* Copyright (C) 2026 Free Software Foundation, Inc.
+
+ This file is part of GDB.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+int target_var = 42;
+
+int
+main (void)
+{
+ asm ("main_label: .globl main_label");
+ return 0;
+}
diff --git a/gdb/testsuite/gdb.dwarf2/multi-piece-inherited-bitfield.exp b/gdb/testsuite/gdb.dwarf2/multi-piece-inherited-bitfield.exp
new file mode 100644
index 00000000000..427828f7178
--- /dev/null
+++ b/gdb/testsuite/gdb.dwarf2/multi-piece-inherited-bitfield.exp
@@ -0,0 +1,151 @@
+# Copyright 2026 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Setup a derived struct that uses multiple inheritance and is described
+# by a multi-piece DWARF location. The second base class contains a
+# bitfield member. At one time, printing such a struct would incorrectly
+# display the bitfield as <synthetic pointer>.
+#
+# The cause was that check_pieced_synthetic_pointer (dwarf2/expr.c)
+# computes the bit offset as 8 * value->offset() but does not add
+# 8 * value->embedded_offset(). When a base subobject is extracted via
+# primitive_field, it gets a non-zero embedded_offset but offset remains
+# zero. check_pieced_synthetic_pointer then checks piece 0 instead of
+# the correct piece, and if piece 0 happens to be an implicit pointer,
+# it incorrectly reports the bitfield as a synthetic pointer.
+
+require allow_cplus_tests
+
+load_lib dwarf.exp
+
+# This test can only be run on targets which support DWARF-2 and use gas.
+require dwarf2_support
+
+standard_testfile .c .S
+
+set asm_file [standard_output_file ${srcfile2}]
+
+# First compile the C file only, so we can query some type sizes.
+if {[prepare_for_testing "failed to prepare" ${testfile} ${srcfile}]} {
+ return
+}
+
+Dwarf::assemble ${asm_file} {
+ cu {} {
+ DW_TAG_compile_unit {
+ DW_AT_language @DW_LANG_C_plus_plus
+ } {
+ declare_labels char_label int_label first_label second_label \
+ derived_label target_label
+ set int_size [get_sizeof "int" -1]
+
+ char_label: DW_TAG_base_type {
+ DW_AT_byte_size 1 DW_FORM_udata
+ DW_AT_encoding @DW_ATE_unsigned_char
+ DW_AT_name "char"
+ }
+
+ int_label: DW_TAG_base_type {
+ DW_AT_byte_size ${int_size} DW_FORM_udata
+ DW_AT_encoding @DW_ATE_signed
+ DW_AT_name "int"
+ }
+
+ first_label: DW_TAG_structure_type {
+ DW_AT_name "First"
+ DW_AT_byte_size 1 DW_FORM_udata
+ } {
+ DW_TAG_member {
+ DW_AT_name "a"
+ DW_AT_type :${char_label}
+ DW_AT_data_member_location 0 DW_FORM_udata
+ }
+ }
+
+ second_label: DW_TAG_structure_type {
+ DW_AT_name "Second"
+ DW_AT_byte_size 1 DW_FORM_udata
+ } {
+ DW_TAG_member {
+ DW_AT_name "bf"
+ DW_AT_type :${int_label}
+ DW_AT_data_member_location 0 DW_FORM_udata
+ DW_AT_bit_size 8 DW_FORM_udata
+ }
+ }
+
+ derived_label: DW_TAG_structure_type {
+ DW_AT_name "Derived"
+ DW_AT_byte_size 2 DW_FORM_udata
+ } {
+ DW_TAG_inheritance {
+ DW_AT_type :${first_label}
+ DW_AT_data_member_location 0 DW_FORM_udata
+ }
+
+ DW_TAG_inheritance {
+ DW_AT_type :${second_label}
+ DW_AT_data_member_location 1 DW_FORM_udata
+ }
+ }
+
+ target_label: DW_TAG_variable {
+ DW_AT_name "target_var"
+ DW_AT_type :${int_label}
+ DW_AT_external 1 DW_FORM_flag
+ DW_AT_location {
+ DW_OP_addr [gdb_target_symbol "target_var"]
+ } SPECIAL_expr
+ }
+
+ DW_TAG_subprogram {
+ MACRO_AT_func { "main" }
+ DW_AT_type :${int_label}
+ DW_AT_external 1 DW_FORM_flag
+ } {
+ DW_TAG_variable {
+ DW_AT_name "d"
+ DW_AT_type :${derived_label}
+ DW_AT_location {
+ DW_OP_GNU_implicit_pointer $target_label 0
+ DW_OP_piece 1
+ DW_OP_const1u 42
+ DW_OP_stack_value
+ DW_OP_piece 1
+ } SPECIAL_expr
+ }
+ }
+ }
+ }
+}
+
+# Now compile both C source and generated DWARF assembly.
+if {[prepare_for_testing "failed to prepare" ${testfile} \
+ [list ${asm_file} ${srcfile}] {}]} {
+ return
+}
+
+# Start the inferior so that 'd' is in scope.
+if {![runto_main]} {
+ return
+}
+
+# With the bug in check_pieced_synthetic_pointer, the bitfield bf in the
+# Second base subobject is incorrectly reported as <synthetic pointer>.
+# This happens because check_pieced_synthetic_pointer does not account for
+# embedded_offset, so it checks piece 0 (the implicit pointer covering
+# First) instead of piece 1 (the stack value covering Second).
+gdb_test "print d" " = {<First> = {a = <synthetic pointer>}, <Second> = {bf = 42}, <No data fields>}" \
+ "bitfield in base subobject is not synthetic pointer"
diff --git a/gdb/testsuite/gdb.dwarf2/multi-piece-primitive-field.exp b/gdb/testsuite/gdb.dwarf2/multi-piece-primitive-field.exp
index 6349d43d67e..4d6b3fcb6c1 100644
--- a/gdb/testsuite/gdb.dwarf2/multi-piece-primitive-field.exp
+++ b/gdb/testsuite/gdb.dwarf2/multi-piece-primitive-field.exp
@@ -47,7 +47,8 @@ Dwarf::assemble ${asm_file} {
DW_TAG_compile_unit {
DW_AT_language @DW_LANG_C_plus_plus
} {
- declare_labels int_label struct_label ref_type_label target_label
+ declare_labels int_label struct_label ref_type_label target_label \
+ first_label second_label derived_label
set int_size [get_sizeof "int" -1]
set addr_size [get_sizeof "void *" -1]
set struct_size [expr {$int_size + $addr_size}]
@@ -80,6 +81,43 @@ Dwarf::assemble ${asm_file} {
}
}
+ first_label: DW_TAG_structure_type {
+ DW_AT_name "first"
+ DW_AT_byte_size ${int_size} DW_FORM_udata
+ } {
+ DW_TAG_member {
+ DW_AT_name "x"
+ DW_AT_type :${int_label}
+ DW_AT_data_member_location 0 DW_FORM_udata
+ }
+ }
+
+ second_label: DW_TAG_structure_type {
+ DW_AT_name "second"
+ DW_AT_byte_size ${addr_size} DW_FORM_udata
+ } {
+ DW_TAG_member {
+ DW_AT_name "ref"
+ DW_AT_type :${ref_type_label}
+ DW_AT_data_member_location 0 DW_FORM_udata
+ }
+ }
+
+ derived_label: DW_TAG_structure_type {
+ DW_AT_name "derived"
+ DW_AT_byte_size ${struct_size} DW_FORM_udata
+ } {
+ DW_TAG_inheritance {
+ DW_AT_type :${first_label}
+ DW_AT_data_member_location 0 DW_FORM_udata
+ }
+
+ DW_TAG_inheritance {
+ DW_AT_type :${second_label}
+ DW_AT_data_member_location ${int_size} DW_FORM_udata
+ }
+ }
+
target_label: DW_TAG_variable {
DW_AT_name "target_var"
DW_AT_type :${int_label}
@@ -105,6 +143,18 @@ Dwarf::assemble ${asm_file} {
DW_OP_piece $addr_size
} SPECIAL_expr
}
+
+ DW_TAG_variable {
+ DW_AT_name "d"
+ DW_AT_type :${derived_label}
+ DW_AT_location {
+ DW_OP_const4u 456
+ DW_OP_stack_value
+ DW_OP_piece $int_size
+ DW_OP_GNU_implicit_pointer $target_label 0
+ DW_OP_piece $addr_size
+ } SPECIAL_expr
+ }
}
}
}
@@ -128,3 +178,13 @@ gdb_test "print s" " = {x = 123, ref = @$hex}" \
gdb_test "print s.ref" " = \\(int &\\) @$hex: 42" \
"print ref member of multi-piece struct"
+
+# Same test but with inheritance. The reference field is in the
+# second base class, so it reaches coerce_pieced_ref through a
+# different path to the above case.
+gdb_test "print d" \
+ " = {<first> = {x = 456}, <second> = {ref = @$hex}, <No data fields>}" \
+ "print inherited multi-piece struct with implicit pointer ref"
+
+gdb_test "print d.ref" " = \\(int &\\) @$hex: 42" \
+ "print ref member of inherited multi-piece struct"
diff --git a/gdb/valops.c b/gdb/valops.c
index c8b27868a8c..ab6fd5079e1 100644
--- a/gdb/valops.c
+++ b/gdb/valops.c
@@ -1545,8 +1545,7 @@ value_addr (struct value *arg1)
if (TYPE_IS_REFERENCE (type))
{
- if (arg1->bits_synthetic_pointer (arg1->embedded_offset (),
- TARGET_CHAR_BIT * type->length ()))
+ if (arg1->bits_synthetic_pointer (0, TARGET_CHAR_BIT * type->length ()))
arg1 = coerce_ref (arg1);
else
{
--
2.25.4
next prev parent reply other threads:[~2026-05-12 10:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-12 10:07 [PATCH 0/6] Fix aggregate types, synthetic pointers, and computed locations bug Andrew Burgess
2026-05-12 10:07 ` [PATCH 1/6] gdb: int to bool conversion in valprint.{c,h} Andrew Burgess
2026-05-13 14:48 ` Tom Tromey
2026-05-12 10:07 ` [PATCH 2/6] gdb: use TARGET_CHAR_BIT more in dwarf2/expr.c Andrew Burgess
2026-05-13 15:05 ` Tom Tromey
2026-05-15 12:00 ` Andrew Burgess
2026-05-15 14:44 ` Tom Tromey
2026-05-12 10:07 ` [PATCH 3/6] gdb: fix coerce_pieced_ref for multi-piece values Andrew Burgess
2026-05-14 18:53 ` Tom Tromey
2026-05-12 10:07 ` [PATCH 4/6] gdb: rename argument in valprint_check_validity Andrew Burgess
2026-05-13 16:23 ` Tom Tromey
2026-05-12 10:07 ` [PATCH 5/6] gdb: remove embedded_offset argument that is always 0 Andrew Burgess
2026-05-13 15:27 ` Tom Tromey
2026-05-12 10:07 ` Andrew Burgess [this message]
2026-05-14 19:00 ` [PATCH 6/6] gdb: use value::embedded_offset in check_pieced_synthetic_pointer Tom Tromey
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=51ce4ffad7667ef14f1d9bd4d7bf2746d410d183.1778579473.git.aburgess@redhat.com \
--to=aburgess@redhat.com \
--cc=gdb-patches@sourceware.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