[Bug symtab/30838] New: [gdb/symtab] Support .debug_types section in .gnu_debugaltlink file

[Bug symtab/30838] New: [gdb/symtab] Support .debug_types section in .gnu_debugaltlink file

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30838

            Bug ID: 30838
           Summary: [gdb/symtab] Support .debug_types section in
                    .gnu_debugaltlink file
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

There are two methods to factor out type information in a dwarf4 executable:
- use -fdebug-info-types to generate type units in a .debug_types section, and
- use dwz to create partial units.

The dwz method has an extra benefit: it also allows to factor out information
between executables into a newly created .dwz file, pointed to by a
.gnu_debugaltlink section.

There is nothing prohibiting a .gnu_debugaltlink file to contain a
.debug_types section.

It's just not generated by dwz atm, and consequently gdb has no support for it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/30838] [gdb/symtab] Support .debug_types section in .gnu_debugaltlink file

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30838

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 15107
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15107&action=edit
partial patch

The patch contains a test-case, and some fixes in the dwarf reader, which allow
the test-case to pass.

It doesn't fix the target board cc-with-gdb-index case though.  The test-case
passes, but the .gdb_index section in the exec is quietly ignored, because
there's no .gdb_index section in the dwz file.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/30838] [gdb/symtab] Support .debug_types section in .gnu_debugaltlink file

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30838

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
I'm not sure it makes sense at this point to explore this further, given that
there's no regular way to generate dwarf like this, but I'd like this PR to
stay open, such that I can reference it from the source code when throwing an
error to say this is unsupported.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/30838] [gdb/symtab] Support .debug_types section in .gnu_debugaltlink file

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30838

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #2)
> when
> throwing an error to say this is unsupported.

https://sourceware.org/pipermail/gdb-patches/2023-September/202354.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/30838] [gdb/symtab] Support .debug_types section in .gnu_debugaltlink file

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30838

--- Comment #4 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=973db6fae304c2bcafff5f169610f663adc9e817

commit 973db6fae304c2bcafff5f169610f663adc9e817
Author: Tom de Vries <tdevries@suse.de>
Date:   Wed Sep 20 16:05:55 2023 +0200

    [gdb/symtab] Error out for .debug_types section in dwz file

    There are two methods to factor out type information in a dwarf4
executable:
    - use -fdebug-info-types to generate type units in a .debug_types section,
and
    - use dwz to create partial units.

    The dwz method has an extra benefit: it also allows to factor out
information
    between executables into a newly created .dwz file, pointed to by a
    .gnu_debugaltlink section.

    There is nothing prohibiting a .gnu_debugaltlink file to contain a
    .debug_types section.

    It's just not generated by dwz or any other tool atm, and consequently gdb
has
    no support for it.  Enhancement PR symtab/30838 is open about the lack of
    support.

    Make the current situation explicit by emitting a dwarf error:
    ...
    (gdb) file struct-with-sig-2^M
    Reading symbols from struct-with-sig-2...^M
    Dwarf Error: .debug_types section not supported in dwz file^M
    ...
    and add an assert in write_gdbindex:
    ...
    +      /* See enhancement PR symtab/30838.  */
    +      gdb_assert (!(per_cu->is_dwz && per_cu->is_debug_types));
    ...
    to clarify why we can use:
    ...
          data_buf &cu_list = (per_cu->is_debug_types
                               ? types_cu_list
                               : per_cu->is_dwz ? dwz_cu_list :
objfile_cu_list);
    ...

    The test-case is a modified copy from gdb.dwarf2/struct-with-sig.exp, so it
    keeps the copyright years range.

    Tested on x86_64-linux.

    Tested-By: Guinevere Larsen <blarsen@redhat.com>

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30838

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/30838] [gdb/symtab] Support .debug_types section in .gnu_debugaltlink file

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30838

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org
           See Also|                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=31363

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/30838] [gdb/symtab] Support .debug_types section in .gnu_debugaltlink file

[sam at gentoo dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30838

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at gentoo dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/30838] [gdb/symtab] Support .debug_types section in .gnu_debugaltlink file

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30838

--- Comment #5 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Simon Marchi <simark@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6474c699a5257f6edfce1132b341f84c0f867f82

commit 6474c699a5257f6edfce1132b341f84c0f867f82
Author: Simon Marchi <simon.marchi@efficios.com>
Date:   Wed Jul 9 11:35:13 2025 -0400

    gdb/dwarf: sort dwarf2_per_bfd::all_units by (section, offset)

    This patch started as a fix for PR 29518 ("GDB doesn't handle
    DW_FORM_ref_addr DIE references correctly with .debug_types sections")
    [1], but the scope has expanded a bit to fix the problem more generally,
    after I spotted a few issues related to the order of all_units.  The
    first version of this patch is here [2].

    PR 29518 shows that dwarf2_find_containing_comp_unit can erroneously
    find a type unit.  The obvious problem is that the
    dwarf2_find_containing_comp_unit function searches the whole all_units
    vector (containing both comp and type units), when really it should just
    search the compilation units.  A simple solution would be to make it
    search the all_comp_units view (which is removed in a patch earlier in
    this series).

    I then realized that in DWARF 5, since type units are in .debug_info
    (versus .debug_types in DWARF 4), type units can be interleaved with
    comp type in the all_units vector.  That would make the all_comp_units
    and all_type_units views erroneous, and dwarf2_find_containing_comp_unit
    could still return something wrong.  In v1, I added a sort in
    finalize_all_units to make sure all_units is in the order that
    dwarf2_find_containing_comp_unit expects:

     - comp units from the main file
     - type units from the main file
     - comp units from the dwz file
     - type units from the dwz file (not actually supported, see PR 30838)

    Another problem I spotted is that the .gdb_index reader creates units in
    this order:

     - comp units from .gdb_index from main file
     - comp units from .gdb_index from dwz file
     - type units from .gdb_index from main file

    This isn't the same order as above, so it would need the same sort step.

    Finally, I'm not exactly sure if and when it happens, but it looks like
    lookup_signatured_type can be called at a later time (after the initial
    scan and creation of dwarf2_per_cu object creation), when expanding a
    symtab.  And that could lead to the creation of a new type unit (see
    function add_type_unit), which would place the new type unit at the end
    of the all_units vector, possibly screwing up the previous order.

    To handle all this in a nice and generic way, Tom Tromey proposed to
    change the all_units order, so that units are sorted by section, then
    section offset.  This is what this patch implements.  The sorting is
    done in finalize_all_units.

    This works well, because when looking up a unit by section offset, the
    caller knows which section the unit is in.  Passing down a (section,
    section offset) tuple makes it clear and unambiguous what unit the
    caller is referring to.  It should help eliminate some bugs where the
    callee used the section offset in the wrong section.  Passing down the
    section along with the section offset replaces the "is_dwz" flag passed
    to dwarf2_find_containing_comp_unit and a bunch of other functions in a
    more general way.

    dwarf2_find_containing_comp_unit can now legitimately find and return
    type units even though it should be needed (type units are typically
    referred to by signature).  But I don't think there is harm for this
    function to be more generic than needed.  I therefore I renamed it to
    dwarf2_find_containing_unit.

    The sort criterion for "section" can be anything, as long as we use the
    same for sorting and searching.  In this patch, I use the pointer to
    dwarf2_section_info, because it's easy.  The downside is that the actual
    order depends on what the memory allocator decided to return, so could
    change from run to run, or machine to machine.  Later, I might change it
    so that sections are ordered based on their properties, making the order
    stable across the board.  This logic is encapsulated in the
    all_units_less_than function, so it's easy to change.

    The .debug_names reader can no longer rely on the order of the all_units
    vector for its checks, since all_units won't be the same order as found
    in the .debug_names lists.  In fact, even before, it wasn't: this check
    assumed that .debug_info had all CUs before TUs, and that the index
    listed them in the exact same order.  When I build a file with gcc and
    "-gdwarf-5 -fdebug-types-section", type units appear first in
    .debug_info.  This caused GDB to reject a .debug_names index that is had
    produced:

        $ GDB="./gdb -nx -q --data-directory=data-directory"
/home/smarchi/src/binutils-gdb/gdb/contrib/gdb-add-index.sh -dwarf-5 hello.so
        $ ./gdb -nx -q --data-directory=data-directory hello.so
        Reading symbols from hello.so...

        â ï¸  warning: Section .debug_names has incorrect entry in CU table,
ignoring .debug_names.

    To make it work, add a new dwarf2_find_unit function that allows looking
    up a unit by start address (unlike dwarf2_find_containing_unit, which
    can find by any containing address), and make the .debug_names reader
    use it.  It might make the load time of .debug_names a bit longer (the
    build and check step is now going to be O(n*log(n)) instead of O(n)
    where n is the number of units, or something like that), but I think
    it's important to be correct here.

    This patch adds a test
    (gdb.dwarf2/dw-form-ref-addr-with-type-units.exp), which tries to
    replicate the problem as shown by PR 29518.

    gdb.base/varval.exp needs a small change, because an error message
    changes (for the better, I think)

    gdb.dwarf2/debug-names-non-ascending-cu.exp now fails, because GDB no
    longer rejects a .debug_names index which lists CUs in a different order
    than .debug_info.  Given the change I did to the .debug_names reader,
    explained above, I don't think this is a problem anymore (GDB can accept
    an index like that).  I also don't think that DWARF 5 mandates that CUs
    are in ascending order.  Delete this test.

    [1] https://sourceware.org/bugzilla/show_bug.cgi?id=29518
    [2]
https://inbox.sourceware.org/gdb-patches/20250218193443.118139-1-simon.marchi@efficios.com/

    Change-Id: I45f982d824d3842ac1eb73f8cce721a0a24b5faa
    Approved-By: Tom Tromey <tom@tromey.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/30838] [gdb/symtab] Support .debug_types section in .gnu_debugaltlink file

[sam at gentoo dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30838

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=30829

-- 
You are receiving this mail because:
You are on the CC list for the bug.