]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit - binutils/ChangeLog
Fix two buglets in .debug_names dumping
authorTom Tromey <tom@tromey.com>
Mon, 4 Dec 2023 14:48:42 +0000 (07:48 -0700)
committerTom Tromey <tom@tromey.com>
Mon, 4 Dec 2023 18:20:44 +0000 (11:20 -0700)
commite0a874120a21bd460bd922c337f4869f72751dcf
tree610559b69347e27e6c0cb5dd73fe3777c48aaf3e
parent9c2370293ebe8354cca0d9dfa745f3bebf238d6d
Fix two buglets in .debug_names dumping

While working on gdb's .debug_names writer, I found a couple of small
bugs in binutils .debug_names dumping.

First, the DWARF spec (section 6.1.1.4.6 Name Table) says:

    These two arrays are indexed starting at 1, [...]

I think it is clearer for binutils to follow this, particularly
because DW_IDX_parent refers to this number.

Second, I think the handling of an empty hash table is slightly wrong.
Currently the dumping code assumes there is always an array of hashes.
However, section 6.1.1.4.5 Hash Lookup Table says:

    The optional hash lookup table immediately follows the list of
    type signatures.

and then:

    The hash lookup table is actually two separate arrays: an array of
    buckets, followed immediately by an array of hashes.

My reading of this is that the hash table as a whole is optional, and
so the hashes will not exist in this case.  (This also makes sense
because the hashes are not useful without the buckets anyway.)

This patch fixes both of these problems.  FWIW I have some gdb patches
in progress that change gdb both to omit the hash table and to use
DW_IDX_parent.

2023-12-04  Tom Tromey  <tom@tromey.com>

* dwarf.c (display_debug_names): Handle empty .debug_names hash
table.  Name entries start at 1.
binutils/ChangeLog
binutils/dwarf.c