[Bug symtab/30775] New: [gdb/symtab] Cannot distinguish between nullptr and dont-know in m_die_range_map

[Bug symtab/30775] New: [gdb/symtab] Cannot distinguish between nullptr and dont-know in m_die_range_map

[vries at gcc dot gnu.org]

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

            Bug ID: 30775
           Summary: [gdb/symtab] Cannot distinguish between nullptr and
                    dont-know in m_die_range_map
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

I wrote a dwarf assembly test-case containing the following dwarf:
...
 <1><be>: Abbrev Number: 3 (DW_TAG_class_type)
    <bf>   DW_AT_specification: <0xcc>
 <1><c3>: Abbrev Number: 4 (DW_TAG_class_type)
    <c4>   DW_AT_specification: <0xbe>
 <1><c8>: Abbrev Number: 5 (DW_TAG_namespace)
    <c9>   DW_AT_name        : N1
 <2><cc>: Abbrev Number: 6 (DW_TAG_class_type)
    <cd>   DW_AT_name        : C1
...
to try and trick the cooked index reader, expecting 0xbe to be deferred but
0xc3 not.

That turned out to be not the case, 0xc3 is also deferred, and consequently we
have N1::C1 for all three class_type DIEs.

The process of how it is deferred is not so pretty though.

The first DIE, 0xbe is deferred because reference 0xcc is beyond the
watermark_ptr (in other words, it's a forward reference).

The second DIE, 0xc3 has a reference to 0xbe which is not beyond the
watermark_ptr (in other words, a backward reference), so it's handled
differently.

First, the parent of 0xbe is looked up in m_die_range_map, which returns
nullptr, not because the parent is nullptr but because 0xbe is deferred and we
don't know the parent yet.

Then scan_attributes recurses into DIE 0xbe, find the same forward reference
and defers DIE 0xc3, ignoring the incorrect parent.

[ We could have saved the trouble of recursing into DIE 0xbe by looking up 0xbe
in m_deferred_entries (and doing that recursively as well to make sure that the
spec_die of the deferred entries is 0xcc in both cases, as is the case in the
current situation).  This would be a minor speed optimization. ]

From the software engineering point of view, looking up some incorrect
information in m_die_range_map and then not using it is problematic.

It's also not clear if that is done intentionally, or just because doing so is
currently not flagged.

In conclusion, we need to be able to query m_die_range_map and be able to
decide  whether the response is:
- parent is null pointer
- don't know the parent
- parent is some valid pointer

Currently we cannot distinguish between the first two options, and we'd like to
assert that queries don't return "don't know the parent" to make sure that we
know if our mechanism for calculating parents of cooked index entries is
failing.

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

[Bug symtab/30775] [gdb/symtab] Cannot distinguish between nullptr and dont-know in m_die_range_map

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
My first attempt at this was to encode nullptr parent as (void *)-1.  [ That
would have made m_die_range_map much bigger, so I started out with a "const
bool m_die_range_map_verify = false" setup. ]

This requires us to explicitly mark nullptr parent, which turns out to be not
nicely isolated in a few spots.

So my current thinking is to maintain a valid_range object alongside
m_die_range_map, and represent the "don't know the parent" case by:
...
(m_die_range_map.find (offset) == nullptr && 
  (outside_valid_range (offset)
   || (inside_valid_range (offset) and m_deferred_entries.find (offset))
...

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