From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id RTqeBnxdGGTE8xQAWB0awg (envelope-from ) for ; Mon, 20 Mar 2023 09:19:56 -0400 Received: by simark.ca (Postfix, from userid 112) id 0AEAB1E223; Mon, 20 Mar 2023 09:19:56 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=H8lKoXQs; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 9C6051E0D3 for ; Mon, 20 Mar 2023 09:19:55 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BF1F13851C04 for ; Mon, 20 Mar 2023 13:19:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BF1F13851C04 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1679318394; bh=rIV3ANJKBEXzLYUpQdTrKQZFFbOkW/LWo77OGbtKpJo=; h=Date:To:Cc:In-Reply-To:Subject:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=H8lKoXQsdADlpxQkwaZ7M8KNFW2cK1+ZIWhXTk4aOyXSDN4s80nPRI1cxzqZs2JIa GfKK42w64Tu4FYhaawk2sT4XtAvIg2wvNgs87NnEzJ4PiX+sy9ZYOFRIJtRldMGUm5 bVNjc5WleRo0IzeTAhNZK02MCc2hKe40idDb+PtY= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 0508A3858D32 for ; Mon, 20 Mar 2023 13:19:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0508A3858D32 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1peFQ6-0003lN-4c; Mon, 20 Mar 2023 09:19:26 -0400 Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1peFQ5-00036T-Kn; Mon, 20 Mar 2023 09:19:25 -0400 Date: Mon, 20 Mar 2023 15:19:33 +0200 Message-Id: <83bkkn8sre.fsf@gnu.org> To: Adrian Oltean Cc: luis.machado@arm.com, gdb@sourceware.org In-Reply-To: (message from Adrian Oltean on Mon, 20 Mar 2023 12:29:25 +0000) Subject: Re: Slow "symbol-file" when using GDB 12.1 on Windows hosts References: <070fbd13-e03c-a4e8-1372-3f7813b7db92@arm.com> <83sfe3ciwy.fsf@gnu.org> <0df63795-2424-52e0-da93-92ab75a6d50f@arm.com> X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Eli Zaretskii via Gdb Reply-To: Eli Zaretskii Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" > From: Adrian Oltean > CC: "gdb@sourceware.org" > Date: Mon, 20 Mar 2023 12:29:25 +0000 > > Eli mentioned that the timestamps offered by Process Monitor are not relevant. However, > I consider that the events and their timestamps are relevant when compared to the > ones generated by GDB 10. There's no attempt to access "C:\Windows\CSC" when > using GDB 10. If that file access wouldn't be attempted by GDB 12, I'm pretty sure > there wouldn't be any slowdown. Any idea why GDB is accessing all those directories? I cannot know what kind of directory structure you have there, and so cannot reason about the directories being accessed by GDB or whether it should access some directory. What are those directories, and why symbol-file causes GDB to access them? > By the way, there's no spike in CPU/memory usage when invoking > "symbol-file" but, on my PC, "C:\Windows\CSC" is completely > inaccessible with my user account. That is probably the real culprit: some directory that needs some special credentials, or which causes GDB to call some network-related resources which are inaccessible or something. So understanding why GDB tries to access that directory and/or making its access faster, might fix your problem. > Maybe you guys can also answer (some of) the questions from my initial email? Which ones?