public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug symtab/30775] New: [gdb/symtab] Cannot distinguish between nullptr and dont-know in m_die_range_map Date: Thu, 17 Aug 2023 11:21:30 +0000 [thread overview] Message-ID: <bug-30775-4717@http.sourceware.org/bugzilla/> (raw) 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.
next reply other threads:[~2023-08-17 11:21 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-08-17 11:21 vries at gcc dot gnu.org [this message] 2023-08-21 10:18 ` [Bug symtab/30775] " vries at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-30775-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).