]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
gdb/dwarf: move index unit vectors to debug names reader and use them
authorSimon Marchi <simon.marchi@efficios.com>
Mon, 10 Mar 2025 16:47:21 +0000 (12:47 -0400)
committerSimon Marchi <simon.marchi@efficios.com>
Mon, 10 Mar 2025 20:09:02 +0000 (16:09 -0400)
commitb3fa38aef59d97a8ce57395b1f3902f6361d9bd4
treed7f4e718ddce44ee2f62def544232d3cf8f6690b
parent30ba744189820f4ae546aa05e905d97e8516bcd2
gdb/dwarf: move index unit vectors to debug names reader and use them

Since these vectors contain the CU and TU lists as found in the
.debug_names header, it seems like they are meant to be used by the
.debug_names reader when handling a DW_IDX_compile_unit or
DW_IDX_type_unit attribute.  The value of the attribute would translate
directly into an index into one of these vectors.

However there's something fishy: it looks like these vectors aren't
actually used in practice.  They are used in the
dwarf2_per_bfd::get_index_{c,t}u methods, which in turn aren't used
anywhere.

The handlers of DW_IDX_compile_unit and DW_IDX_type_unit use the
dwarf2_per_bfd::get_cu method, assuming that all compile units are
placed before type units in the dwarf2_per_bfd::all_units vector.  I see
several problems with that:

 1. I found out [1] that the dwarf2_per_bfd::all_units didn't always
    have the CUs before the TUs.  So indexing dwarf2_per_bfd::all_units
    with that assumption will not work.

 2. The dwarf2_find_containing_comp_unit function assumes an ordering of
    units by section offset (among other criteria) in order to do a
    binary search.  Even though it's probably commonly the case, nothing
    guarantees that the order of CUs and TUs in the .debug_names header
    (which defines the indices used to refer to them) will be sorted by
    section offset.  It's not possible to make
    dwarf2_find_containing_comp_unit (assuming it wants to do a binary
    search by section offset) and the DW_IDX_compile_unit /
    DW_IDX_type_unit handlers use the same vector.

 3. I have not tested this, but in the presence of a dwz supplementary
    file, the .debug_names reader should probably not put the units from
    the main and dwz files in the same vectors to look them up by index.
    Presumably, if both the main and dwz files have a .debug_names
    index, they have distinct CU / TU lists.  So, an CU index of 1 in an
    index entry in the main file would refer to a different CU than an
    index of 1 in an index entry in the dwz file.  The current code
    doesn't seem to account for that, it just indexes
    dwarf2_per_bfd::all_units.

Since those vectors are kind of specific to the .debug_names reader,
move them there, in the mapped_debug_names_reader struct.  Then, update
the handlers of DW_IDX_compile_unit and DW_IDX_type_unit to use them.

[1] https://inbox.sourceware.org/gdb-patches/87a5ab5i5m.fsf@tromey.com/T/#mbdcfe35f94db33e59500eb0d3d225661cab016a4

Change-Id: I3958d70bb3875268143471da745aa09336ab2500
gdb/dwarf2/read-debug-names.c
gdb/dwarf2/read.h