From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9D4C538618BD; Wed, 10 Jan 2024 18:37:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9D4C538618BD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1704911853; bh=4UNMv0JvSg7jehJWlhh7Nk21G4du0lfXOwr56Z111u0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=XwC2AkWUZnHKS+O2DWvHd2sIKjq/tN3IKC3CcDxcJmdciAqIMp0Xcsi0pkaWyYT3o MB9aHjrZ2cdDTb8XOh2iE7myCfCwcYkh6rLSoRt5JPsJmGQ91krOr51tf2/VFiKy4b 4YnvxXRtnX6KOycuhrwFmn+eGHJI3l7xxxW8Z/2c= From: "dblaikie at gmail dot com" To: gdb-prs@sourceware.org Subject: [Bug symtab/24820] .debug_names has incorrect contents Date: Wed, 10 Jan 2024 18:37:30 +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: dblaikie at gmail dot com 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 #11 from David Blaikie --- Hey Tom - catching up on this bug & giving whatever context I have from DWA= RF and Clang. It'd be great to get this working for Clang/GCC/GDB/LLDB to have a portable index that provides good performance for at least both GDB and LLDB, and ma= ybe other consumers - but two would at least be a good start. If there are bugs in clang, we're interested in fixing them. If there are bugs/unclear things in the DWARF spec, we're interested in fix= ing them. > However, it is required for .debug_names to work properly. I don't think that's true - at least doesn't seem to be true for lldb. Maybe this dovetails into: > gdb needs to know the CU language but this isn't in the tables. gdb can e= mit it as an extension of course. I suppose we could read the first DIE of= every CU -- but that's precisely the kind of work we want to avoid. Yeah, that's what I'd recommend for the language and address ranges - readi= ng the first DIE of each CU. My experience is that's still quite cheap and qui= te a different proposition compared to "read all the DIEs and discover all the n= ames from scratch". (I wouldn't be averse to a new DWARFv5+ version of "aranges" that points to= the rnglist the CU points to anyway - it'd add some overhead compared to discovering the ranges by reading the first DIE, but would be slightly fast= er too - but the current aranges are really verbose/totally duplicate with the rnglist for the CU - Clang hasn't emitted aranges by default for a decade o= r so because the size/perf tradeoff wasn't great) > Oh, finally, the hash table is useless to gdb, so I think gdb should simp= ly not emit it. That surprises me - does gdb_index not contain some kind of fast lookup? Or= is it a flat list that gdb loads on startup into a hash table? Could gdb benefit from using the hash table, or are there some architectural reasons that's infeasible? > Well, maybe this isn't really fair, the missing parentage is maybe just a= clang bug, not a bug in the spec. The spec doesn't mandate the parent references - but the Apple LLDB folks (they're in the process of moving to DWARFv5, so they're finding all the regressions in .debug_names compared to the original .apple_names that were introduced in the standardization process) are in the process of adding the parent links to Clang's output. https://github.com/llvm/llvm-project/pull/7= 7457 and related work/discussions. > gdb will have to mark some entries as linkage names. Otherwise there's no way to tell. Is it not enough to check the mangling prefix? If it starts with `_Z` or another mangling prefix, it's a mangled name otherwise it's the name? (unle= ss you need to differentiate the other direction - that a name isn't the linka= ge name, but flagging linkage names wouldn't be enough for that (if you have DW_AT_name "foo" you couldn't tell if that's a C linkage function where the name matches the linkage name, or a C++ linkage function where it's overloaded/etc and has some other linkage name)) Interested in understanding that more. > It's kind of sad that DWARF invented a new format and then didn't provide= enough guidance for tools to be compatible at all. Happy to hear more about what guidance is missing/clarify things, if some things that the spec says are optional are basically necessities, we could = make them mandatory in future DWARF versions, etc. > In the case of libxul, the combined size of its .debug_names, .debug_str = and .debug_aranges is about 72% larger than the size of its .gdb_index (690= MB vs. 400 MB). At least for this library we are much better off sticking= with .gdb_index. Yeah, that's something that's concerned me a bit too - including the .o representation of .debug_names (at Google I've been mostly concerned with .o file sizes - the aggregate size of the objects needed by the linker in some large Google programs is quite problematic)... so, again, interested to know more about whether there are ways we could improve the format to be more de= nse or terse. --=20 You are receiving this mail because: You are on the CC list for the bug.=