From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 03F43385E838; Wed, 10 Jan 2024 20:51:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 03F43385E838 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1704919916; bh=xwr04pLs0vYbcdEDh5/iherCNzuplrBGjZ/+R50gcKc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GT3hAg/U43Cx0FTyNdz+oOdfHmyOyhfqP0YBd8BBHexQFN7t07OblI0axn6Ae6brL 6Edi7ydjdN2GkC+UvZduI5HOAnbU3zwM7ca8c8rKVKWS1LZdvKLAnBJGgvel0Syi4L 6nv6FVd9zQltDSUqc/bKjXm8Mug11rYsd2M8hHj0= From: "tromey at sourceware dot org" To: gdb-prs@sourceware.org Subject: [Bug symtab/24820] .debug_names has incorrect contents Date: Wed, 10 Jan 2024 20:51:54 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: symtab X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: tromey at sourceware dot org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: tromey at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D24820 --- Comment #12 from Tom Tromey --- Thanks for your notes. My impression is that ranges can't reliably be reconstructed from just the top DIE, but that a full scan must be done. I'm not really sure about this -- possibly this is only true for older compiler or something. But gdb supports some truly=20 awful crud so maybe we're stuck. If it does work, we could certainly implement it though. That would solve the language problem as well... it's not great to have to scan abbrevs and whatnot like that, but meh, that's DWARF for you. About the hash table: gdb_index is basically just a hash table. It explicitly uses the gdb canonicalized form of symbols. This makes it possible to do lookups. I think completion is done by walking all the names.=20=20 For debug_names (after this bug is fixed), though, the scanner creates the "cooked" internal form (same that the DWARF scanner creates). This lets us share data structures, lookup code, etc. This code doesn't use a hash table at all, so adding one seemed like extra work. And since canonicalization isn't really solved in the spec or in the written hash table, we'd have to do some kind of secondary backward map (from canonical form to lookup form) to use it. (It's not just gcc that doesn't canonicalize names btw, there's another bug from some other vendor in this area.) For the linkage name flag: I see gdb uses this in two spots. One spot is when constructing the full name of an entry. There's probably some test where a linkage name is in some scope, and this approach was expedient. We could just register these without parents. However, it's also used in gdb's post-scanning finalization step. This is gross but some languages don't emit DWARF hierarchical forms. So, for instance, for Ada gdb will synthesize the package names for a fully-qualified symbol. Also it isn't reliable to look for _Z for linkage names. This works for C++ and to some extent Rust (Rust is / will be switching mangling schemes), but not for Go, Ada, Fortran. --=20 You are receiving this mail because: You are on the CC list for the bug.=