Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@efficios.com>
To: gdb-patches@sourceware.org
Cc: Simon Marchi <simon.marchi@polymtl.ca>
Subject: [PATCH 3/6] gdb/testsuite/dwarf: emit type unit sections as COMDAT
Date: Fri,  7 Nov 2025 16:10:14 -0500	[thread overview]
Message-ID: <20251107211041.520697-4-simon.marchi@efficios.com> (raw)
In-Reply-To: <20251107211041.520697-1-simon.marchi@efficios.com>

From: Simon Marchi <simon.marchi@polymtl.ca>

In an effort to generate ELF files and DWARF info as close as possible
as an actual compiler would generate, change how we emit type unit
sections to emit each type unit in its own section, in COMDAT section
groups.

We currently emit all type units in a single, standard section (either
.debug_info or .debug_types, depending on the DWARF version).  Compilers
emit each type unit in its own .debug_types section.  Each section is
placed in a COMDAT section group with a signature based on the type
unit's signature.  This lets the linker deduplicate identical type units
by discarding section groups with identical signatures (keeping only one
group with a given signature).

Looking at a .s file generated by gcc, we can see that this is how it
specifies the section for a type unit:

    .section .debug_info,"G",@progbits,wi.006fd2152a3054a6,comdat

The "G" flag tells the assembler to place the section in a section
group with signature "wi.006fd2152a3054a6".  That string was generated
from the type unit, signature.  Finally, the comdat linkage field
indicates that the section group should have the COMDAT flag.

Update the tu proc to emit a section with these properties.  In this
case, it's mandatory to specify the type of the section (progbits).

Update the _section proc to accept the new options "group_signature" and
"linkage".

As a result, if you look at the .debug_types section in a .o file from
gcc:

    $ readelf -g main.o
    COMDAT group section [    1] `.group' [wt.006fd2152a3054a6] contains 2 sections:
       [Index]    Name
       [   11]   .debug_types
       [   12]   .rela.debug_types

    COMDAT group section [    2] `.group' [wt.c621aa8e3c23e450] contains 2 sections:
       [Index]    Name
       [   13]   .debug_types
       [   14]   .rela.debug_types

And a .o file created by our DWARF assembler:

    $ readelf -g testsuite/outputs/gdb.dwarf2/struct-with-sig/struct-with-sig1.o
    COMDAT group section [    1] `.group' [sig.0x0000000000000001] contains 2 sections:
       [Index]    Name
       [   10]   .debug_types
       [   11]   .rela.debug_types

    COMDAT group section [    2] `.group' [sig.0x0000000000000002] contains 2 sections:
       [Index]    Name
       [   12]   .debug_types
       [   13]   .rela.debug_types

In both cases, in the fully linked files, there is a single .debug_types section
containing the two type units, as expected.

Before this patch, when I run gdb.dwarf2/fission-with-type-unit.exp, the
resulting .dwo file has a single .debug_info.dwo.  After this patch it
has two: one with the type unit and one with the compile unit (the test
uses DWARF 5).  Based on what I see gcc generate when using "-gdwarf-5
-gsplit-dwarf -fdebug-types-section", this is what we expect.

Change-Id: Ie1954dc697fe100b5dbe664d148c71fa02888d96
---
 gdb/testsuite/lib/dwarf.exp | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/lib/dwarf.exp b/gdb/testsuite/lib/dwarf.exp
index 5536b7656b8c..c3c35d43607d 100644
--- a/gdb/testsuite/lib/dwarf.exp
+++ b/gdb/testsuite/lib/dwarf.exp
@@ -1075,6 +1075,8 @@ namespace eval Dwarf {
 	parse_options {
 	    { flags "" }
 	    { type "" }
+	    { group_signature "" }
+	    { linkage "" }
 	}
 
 	set directive ".section $name"
@@ -1097,6 +1099,14 @@ namespace eval Dwarf {
 	    append directive ", %$type"
 	}
 
+	if { $group_signature != "" } {
+	    append directive ", $group_signature"
+	}
+
+	if { $linkage != "" } {
+	    append directive ", $linkage"
+	}
+
 	_emit "        $directive"
     }
 
@@ -1717,7 +1727,13 @@ namespace eval Dwarf {
 	    set _abbrev_section "$_abbrev_section.dwo"
 	}
 
-	_section $section
+	# The specific format of the signature is arbitrary.
+	_section $section {
+	    flags G
+	    type progbits
+	    group_signature sig.$signature
+	    linkage comdat
+	}
 
 	set cu_num [incr _cu_count]
 
-- 
2.51.2


  parent reply	other threads:[~2025-11-07 21:12 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-07 21:10 [PATCH 0/6] Type unit + split DWARF fixes (PR 33307) Simon Marchi
2025-11-07 21:10 ` [PATCH 1/6] gdb/testsuite/dwarf: use single abbrev table in .dwo files Simon Marchi
2025-11-10 20:14   ` Simon Marchi
2025-11-18 13:32     ` Andrew Burgess
2025-11-18 16:50       ` Simon Marchi
2025-11-18 16:55   ` Andrew Burgess
2025-11-18 17:20     ` Simon Marchi
2025-11-19 16:05       ` Tom Tromey
2025-11-19 20:21         ` Simon Marchi
2025-11-07 21:10 ` [PATCH 2/6] gdb/testsuite/dwarf: convert _section proc to use parse_options Simon Marchi
2025-11-19 10:59   ` Andrew Burgess
2025-11-19 15:53   ` Tom Tromey
2025-11-19 20:40     ` Simon Marchi
2025-11-19 21:03       ` Tom Tromey
2025-11-07 21:10 ` Simon Marchi [this message]
2025-11-19 11:43   ` [PATCH 3/6] gdb/testsuite/dwarf: emit type unit sections as COMDAT Andrew Burgess
2025-11-07 21:10 ` [PATCH 4/6] gdb/dwarf: when in dwarf2_cu, read addr_size from dwarf2_cu::header Simon Marchi
2025-11-19 14:30   ` Andrew Burgess
2025-11-19 20:46     ` Simon Marchi
2025-11-19 16:11   ` Tom Tromey
2025-11-19 20:51     ` Simon Marchi
2025-11-07 21:10 ` [PATCH 5/6] gdb/dwarf: store addr/offset/ref_addr sizes in dwarf2_per_cu Simon Marchi
2025-11-19 14:42   ` Andrew Burgess
2025-11-19 16:14   ` Tom Tromey
2025-11-21 19:54     ` Simon Marchi
2025-11-21 21:25       ` Tom Tromey
2025-11-07 21:10 ` [PATCH 6/6] gdb/dwarf: use dwarf2_per_cu::ref_addr_size in one spot Simon Marchi
2025-11-19 14:44   ` Andrew Burgess

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=20251107211041.520697-4-simon.marchi@efficios.com \
    --to=simon.marchi@efficios.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simon.marchi@polymtl.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