[gdb/symtab] Revert "Change handling of DW_TAG_enumeration_type in DWARF scanner"HEADmaster

After adding dwarf assembly to test-case gdb.dwarf2/enum-type.exp that adds
this debug info:
...
 <1><11f>: Abbrev Number: 3 (DW_TAG_enumeration_type)
    <120>   DW_AT_specification: <0x130>
 <2><124>: Abbrev Number: 4 (DW_TAG_enumerator)
    <125>   DW_AT_name        : val1
    <12a>   DW_AT_const_value : 1
 <2><12b>: Abbrev Number: 0
 <1><12c>: Abbrev Number: 5 (DW_TAG_namespace)
    <12d>   DW_AT_name        : ns
 <2><130>: Abbrev Number: 6 (DW_TAG_enumeration_type)
    <131>   DW_AT_name        : e
    <133>   DW_AT_type        : <0x118>
    <137>   DW_AT_declaration : 1
...
I run into an assertion failure:
...
(gdb) file enum-type^M
Reading symbols from enum-type...^M
cooked-index.h:214: internal-error: get_parent: \
  Assertion `(flags & IS_PARENT_DEFERRED) == 0' failed.^M
...

This was reported in PR32160 comment 1.

This is a regression since commit 4e417d7bb1c ("Change handling of
DW_TAG_enumeration_type in DWARF scanner").

Fix this by reverting the commit.

[ Also drop the kfails for PR31900 and PR32158, which are regressions by that
same commit. ]

That allows us to look at the output of "maint print objfiles", and for val1
we get an entry without parent:
...
    [27] ((cooked_index_entry *) 0x7fbbb4002ef0)
    name:       val1
    canonical:  val1
    qualified:  val1
    DWARF tag:  DW_TAG_enumerator
    flags:      0x0 []
    DIE offset: 0x124
    parent:     ((cooked_index_entry *) 0)
...
which is incorrect, as noted in that same comment, but an improvement over the
assertion failure, and I don't think that ever worked.  This is to be
addressed in a follow-up patch.

Reverting the commit begs the question: what was it trying to fix in the first
place, and do we need a different fix?  I've investigated this and filed
PR32160 to track this.

My guess is that the commit was based on a misunderstand of what we track
in cooked_indexer::m_die_range_map.

Each DIE has two types of parent DIEs:
- a DIE that is the parent as indicated by the tree structure in which DIEs
  occur, and
- a DIE that represent the parent scope.

In most cases, these two are the same, but some times they're not.

The debug info above demonstrates such a case.  The DIE at 0x11f:
- has a tree-parent: the DIE representing the CU, and
- has a scope-parent: DIE 0x12c representing namespace ns.

In cooked_indexer::m_die_range_map, we track scope-parents, and the commit
tried to add a tree-parent instead.

So, I don't think we need a different fix, and propose we backport the reversal
for gdb 15.2.

Tested on x86_64-linux.

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

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31900
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32158
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32160

0 files changed, 0 insertions, 0 deletions