From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 10A343877216; Wed, 14 Dec 2022 10:23:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 10A343877216 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1671013419; bh=AplxUlNFClV7sg7GSFHtISlHR8fD0QRAfUEpg6K5eTA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qJQ6ZHtBG7jn+QXyhPoQiPxR2hzcYMZigzm/ZrJ86JyOCKnYicHzEJ/xIxAQuFILq CM09N55FfB8E5NQQQ7T91oUMB8HsNJXETEbmYn0KG9/kiiOXqa7kiTbBK35OGJZQxk UMKlJ91pJYVyq6mYZl9R0KGkr2AlC9IOYNvPpWbU= From: "cvs-commit at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug symtab/29105] new DWARF reader still slow Date: Wed, 14 Dec 2022 10:23:37 +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: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: tromey at sourceware dot org X-Bugzilla-Target-Milestone: 13.1 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=3D29105 --- Comment #29 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Andrew Burgess : https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3D9f50fe083585= 0645bd8ea9bb1efe1fe6c48dfb12 commit 9f50fe0835850645bd8ea9bb1efe1fe6c48dfb12 Author: Andrew Burgess Date: Wed Dec 7 15:55:25 2022 +0000 gdb/testsuite: new test for recent dwarf reader issue This commit provides a test for this commit: commit 55fc1623f942fba10362cb199f9356d75ca5835b Date: Thu Nov 3 13:49:17 2022 -0600 Add name canonicalization for C Which resolves PR gdb/29105. My reason for writing this test was a desire to better understand the above commit, my process was to study the commit until I thought I understood it, then write a test to expose the issue. As the original commit didn't have a test, I thought it wouldn't hurt to commit this upstream. The problem tested for here is already described in the above commit, but I'll give a brief description here. This description describes GDB prior to the above commit: - Builtin types are added to GDB using their canonical name, e.g. "short", not "signed short", - When the user does something like 'p sizeof(short)', then this is handled in c-exp.y, and results in a call to lookup_signed_type for the name "int". The "int" here is actually being looked up as the type for the result of the 'sizeof' expression, - In lookup_signed_type GDB first adds a 'signed' and looks for that type, so in this case 'signed int', and, if that lookup fails, GDB then looks up 'int', - The problem is that 'signed int' is not the canonical name for a signed int, so no builtin type with that name will be found, GDB will then go to each object file in turn looking for a matching type, - When checking each object file, GDB will first check the partial symtab to see if the full symtab should be expanded or not. Remember, at this point GDB is looking for 'signed int', there will be no partial symbols with that name, so GDB will not expand anything, - However, GDB checks each partial symbol using multiple languages, not just the current language (C in this case), so, when GDB checks using the C++ language, the symbol name is first canonicalized (the code that does this can be found lookup_name_info::language_lookup_name). As the canonical form of 'signed int' is just 'int', GDB then looks for any symbols with the name 'int', most partial symtabs will contain such a symbol, so GDB ends up expanding pretty much every symtab. The above commit fixes this by avoiding the use of non-canonical names with C, now the initial builtin type lookup will succeed, and GDB never even considers whether to expand any additional symtabs. The test case creates a library that includes char, short, int, and long types, and a test program that links against the library. In the test script we start the inferior, but don't allow it to progress far enough that the debug information for the library has been fully expanded yet. Then we evaluate some 'sizeof(TYPE)' expressions. In the buggy version of GDB this would cause the debug information for the library to be fully expanded, while in the fixed version of GDB this will not be the case. We use 'info sources' to determine if the debug information has been fully expanded or not. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29105 --=20 You are receiving this mail because: You are on the CC list for the bug.=