From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 66AFD3858D1E; Sun, 12 Feb 2023 16:25:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 66AFD3858D1E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1676219104; bh=kAzSALktznj6NpGivslCo4DTah44ioJ1U2cUuHizCIE=; h=From:To:Subject:Date:From; b=YuwnakipSkbswQyZeL0UHCH2nEY7ivETqmyiYD6taQTQer0l33Qo7qAtpnRTyHwaX YpQSzByLK7WHyZaKiPVqXtJtIK2k2jCvWc0DgWAL5M2lsJeoazq7xc3OhDLubgNSnn N2OdDezt+ELwnT/Hx0Tx3AWohic4i/jCLNf44YA0= From: "tromey at sourceware dot org" To: gdb-prs@sourceware.org Subject: [Bug rust/30116] New: "start" fails for Rust with new DWARF indexer Date: Sun, 12 Feb 2023 16:25:04 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: rust X-Bugzilla-Version: HEAD 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: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: 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=3D30116 Bug ID: 30116 Summary: "start" fails for Rust with new DWARF indexer Product: gdb Version: HEAD Status: NEW Severity: normal Priority: P2 Component: rust Assignee: unassigned at sourceware dot org Reporter: tromey at sourceware dot org Target Milestone: --- On irc, Iain Buclaw pointed out that the new DWARF indexer broke "start" for D. This is easily fixed, but more testing showed that it also broke Rust. It's not entirely trivial to fix. The issue is that in dwarf2_build_psymtabs_hard: const cooked_index_entry *main_entry =3D vec->get_main (); if (main_entry !=3D nullptr) set_objfile_main_name (objfile, main_entry->name, main_entry->per_cu->lang ()); ... here we'd like to use the entry's full name. But, the entry hasn't been canonicalized yet, so doing this would actually crash. Note though that Rust doesn't require canonicalization. And, the languages that do require canonicalization don't need this mechanism for finding "main". So, I think at least for now we could have a hack to handle this. Longer term, perhaps resurrecting an old patch of mine to make "main"-finding more lazy (lookup on first use) would be good. This way the index could be "clean" and wait for the finalization to be done, while not pausing the UI in the normal case... the problem with the current code being that for "gdb exe", gdb eagerly wants to set the current language, but really this could be done on demand. --=20 You are receiving this mail because: You are on the CC list for the bug.=