From: Andrew Burgess <aburgess@redhat.com>
To: Simon Marchi <simon.marchi@efficios.com>, gdb-patches@sourceware.org
Cc: Simon Marchi <simon.marchi@polymtl.ca>
Subject: Re: [PATCH 3/6] gdb/testsuite/dwarf: emit type unit sections as COMDAT
Date: Wed, 19 Nov 2025 11:43:20 +0000 [thread overview]
Message-ID: <87ms4itfhj.fsf@redhat.com> (raw)
In-Reply-To: <20251107211041.520697-4-simon.marchi@efficios.com>
Simon Marchi <simon.marchi@efficios.com> writes:
> 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.
I think I followed all of this.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Thanks,
Andrew
>
> 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
next prev parent reply other threads:[~2025-11-19 11:44 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 ` [PATCH 3/6] gdb/testsuite/dwarf: emit type unit sections as COMDAT Simon Marchi
2025-11-19 11:43 ` Andrew Burgess [this message]
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=87ms4itfhj.fsf@redhat.com \
--to=aburgess@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=simon.marchi@efficios.com \
--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