From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx07-00178001.pphosted.com (mx07-00178001.pphosted.com [185.132.182.106]) by sourceware.org (Postfix) with ESMTPS id 229DD3858426 for ; Fri, 6 Oct 2023 21:09:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 229DD3858426 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=foss.st.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=foss.st.com Received: from pps.filterd (m0369458.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.22/8.17.1.22) with ESMTP id 396E3kql004775; Fri, 6 Oct 2023 23:09:44 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h= message-id:date:mime-version:subject:to:references:from :in-reply-to:content-type:content-transfer-encoding; s= selector1; bh=OlXdJR8AWCrz8HQERivn9nGKMWUTROyjo5RjjfAEpUc=; b=LO u/QYBrfsyC+WpF8XUWqWwTISIgxgkpqaqrnwjvYOF3+QWLaNY7LchrlCessbxyqK RxhAsmos1leGrU7GzPKKWe35+unms/V2pJBHNeqz+urmh5foHyoQeMYtlG/+AhBb ZHww2+1rKNYaeCqzC/F1/KbxGnzZ/JNhtc9IW4GST8Y7zKvlH1u3w9znCAGJpOc3 /o7yaZ8WQ+FdhBTD0ybht3mrAPxZ1BvgQ+Y4nah4Ce+VowEnGZlHPABNMS161vyJ +RRhNwLNCLm3NwvWq+27F70WlHqcqJ8EU1zulzsLP1ICOAWmQBEMM1UJKgvygN2a HFdZ8VAMbKEurUX1yLCg== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3tj06tn7mq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 06 Oct 2023 23:09:44 +0200 (MEST) Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 1D2C2100053; Fri, 6 Oct 2023 23:09:44 +0200 (CEST) Received: from Webmail-eu.st.com (shfdag1node3.st.com [10.75.129.71]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 11BB320A75A; Fri, 6 Oct 2023 23:09:44 +0200 (CEST) Received: from [10.252.31.89] (10.252.31.89) by SHFDAG1NODE3.st.com (10.75.129.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Fri, 6 Oct 2023 23:09:43 +0200 Message-ID: <3d574beb-7a1d-ac3d-bebd-d4e85ee185c8@foss.st.com> Date: Fri, 6 Oct 2023 23:09:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] bfd: add new bfd_cache_size() function Content-Language: en-US To: Andrew Burgess , References: From: Torbjorn SVENSSON In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.252.31.89] X-ClientProxiedBy: SHFCAS1NODE2.st.com (10.75.129.73) To SHFDAG1NODE3.st.com (10.75.129.71) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-10-06_15,2023-10-06_01,2023-05-22_02 X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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: On 2023-10-06 18:03, Andrew Burgess via Binutils wrote: > In GDB we have a problem with the BFD cache. > > As GDB runs for a potentially extended period of time, if the BFD > cache holds a file descriptor for an open on-disk file, this can, on > some targets (e.g. Win32) prevent the OS writing to the file. > > This might, for example, prevent a user from recompiling their > executable as GDB is (via the BFD cache) holding an open reference to > that file. > > Another problem, relates to bfd_stat, for BFDs that are using the BFD > cache (i.e. they call cache_bstat to implement bfd_stat). The > cache_bstat function finds the BFD in the cache, opening the file if > needed, and then uses fstat on the open file descriptor. > > What this means is that, if the on-disk file changes, but the cache > was holding an open reference to the file, the bfd_stat will return > the 'struct stat' for the old file, not the new file. > > Now, for this second problem, we might be tempted to make use of an > actual stat call, instead of calling bfd_stat, however, this isn't > ideal as we have some BFDs that use a custom iovec, and implement the > various functions over GDB's remote protocol. By using bfd_stat we > can have a single call that should work for both local files, and for > remote files. > > To solve both of these problems GDB has calls to bfd_cache_close_all > sprinkled around its code base. And in theory this should work fine. > > However, I recently ran into a case where we had missed a > bfd_cache_close_all call, and as a result some BFDs were held open. > This caused a bfd_stat call to return an unexpected result (old file > vs new file). > > What I'd like is some way within GDB that I can do: > > gdb_assert ( /* Nothing is held open in the cache. */ ); > > As this would allow GDB to quickly identify when we've missed some > bfd_cache_close_all calls. > > And so, to support this, I would like to add a new bfd_cache_size > function. This function returns an integer, which is the number of > open files in the cache. I can then start adding: > > gdb_assert (bfd_cache_size() == 0); > > to GDB in some strategic spots, and start fixing all of the missing > bfd_cache_close_all calls that crop up as a result. I think this sounds reasonable, but I'm not a maintainer so you need someone else to approve this.