From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 0E8B33858C50 for ; Fri, 29 Sep 2023 15:18:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0E8B33858C50 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org 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 1qmFGE-00024B-7c; Fri, 29 Sep 2023 11:18:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=CQBqr8onqIPb+cKpheHeqtAtBwp0ha6pZEoMiGgfSDE=; b=rZX/7nQJwp1q Sg+nL4iqdiUaObOwLdJH2PwJyxZRE+38avW+5CaPn7N4XIIpB+ST0Hxm2UE7v7ylobQshoqprMZFw riir0+fM7EhFK2q0C/uT3V3CIUiYtHvuGf9iQNwsZfFcOBwco0ve+BmTuc8urG2CY/zhXyplxyYD1 glJ6j/Naz1up3mW0B7AuD7FIkg1hggho/8d408PZZ16n/dRxq34koV9SOO2Zm6FYaS6NuxBOP0B2s vBvmwMkimSBwfEXV0meE24Qz35p/ki5xR4N/Y+m91atLf4EMRxzENzpJaFMgq9BUEdmDLNCbOyJcY fh99mC2ONAGWmVmFBnuUTg==; Date: Fri, 29 Sep 2023 18:18:15 +0300 Message-Id: <838r8pypmw.fsf@gnu.org> From: Eli Zaretskii To: Andrew Burgess Cc: tromey@adacore.com, gdb-patches@sourceware.org In-Reply-To: <87sf6xuvvb.fsf@redhat.com> (message from Andrew Burgess via Gdb-patches on Fri, 29 Sep 2023 11:17:12 +0100) Subject: Re: [PATCH 9/9] gdb: use reopen_exec_file from reread_symbols References: <87msxi8dcv.fsf@tromey.com> <877coawcd9.fsf@redhat.com> <87msx62mh5.fsf@tromey.com> <87sf6xuvvb.fsf@redhat.com> X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > Cc: Tom Tromey , Andrew Burgess via Gdb-patches > > Date: Fri, 29 Sep 2023 11:17:12 +0100 > From: Andrew Burgess via Gdb-patches > > Here is the text from the older (unfound) thread that is quoted: > > > When the inferior is killed, it is safe the release the different file > > handles that BFD keeps open. It is particularly useful on Win32 (and > > presumably on HP UX) to be able to recompile and restart a new debugging > > session without quitting GDB... > > Now I've never done any development work on Win32, I very occasionally > boot a Windows machine to do a test build of GDB, but beyond that my > knowledge of Windows is like 20+ years old :-/ However, I do have a > vague memory that Windows didn't like you writing to a file that was > opened by some other application? Maybe this memory is wrong, but that > would seem to align with the above text. Yes, Windows will not allow you to write to a file opened by another process. (It is possible to open a file in a "shared" mode which will then allow that, but few applications do that, and the default is not "shared".) > If that is the case, then it would seem (to me) that we want to ensure > BFD is not holding open any files at a time when GDB itself is not > actively doing anything that might read from a file, this would be: > > 1. When GDB is sat idle at a prompt, and > > 2. When GDB is blocked waiting for an inferior event. Right. The best would be for GDB to open the file, read from or write to it, then close it immediately when it's done with it.