From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omta34.uswest2.a.cloudfilter.net (omta34.uswest2.a.cloudfilter.net [35.89.44.33]) by sourceware.org (Postfix) with ESMTPS id 50C18385C6C4 for ; Fri, 27 Oct 2023 19:30:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 50C18385C6C4 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 50C18385C6C4 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=35.89.44.33 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698435044; cv=none; b=WMMfqc67f6UWXXZUH3gXYMC/Ze8s0jbEhTU5tMopHA0WA/2b2ijU8euoK4Xt/LN3m2PyXd9SVZp0/UYn5W7nVrW3ZNicX7/x0HEWsBKhlZ/UVG2/2XHxfAbP6KK8JaVPzu7/1Zp5kLp9hcuYelz0eizFhLhxQeCBP2MvUVz8vZw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698435044; c=relaxed/simple; bh=Ewdl9/ga12r0Px6CMsa5r1JmCewxwrnnpC2TunWWw98=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=xYlVTeNZS5UhwGIHwvd+lAvklWAFT0b0oc/vgSqKoQxqSe/pBNlVOKbeoUDGBGzG1FLbBHO+Hbxa/ZCHWUHNK5oTgXJ0dzQ0G12NE/wVfNXGu1/cjOEWXhrl053wGnYJEZGqdmjRlwlnuxihoGur9w3wm1PXwcCrhgS92Vfo4LY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from eig-obgw-5006a.ext.cloudfilter.net ([10.0.29.179]) by cmsmtp with ESMTPS id wMRZqgIeW8HtewSXXq4HDZ; Fri, 27 Oct 2023 19:30:39 +0000 Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTPS id wSXWqWZaFULW5wSXWq0OXH; Fri, 27 Oct 2023 19:30:39 +0000 X-Authority-Analysis: v=2.4 cv=Yusc+qUX c=1 sm=1 tr=0 ts=653c0fdf a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=OWjo9vPv0XrRhIrVQ50Ab3nP57M=:19 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=bhdUkHdE2iEA:10 a=Qbun_eYptAEA:10 a=20KFwNOVAAAA:8 a=Fazc32XKx6ewiXr5V2kA:9 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=5wjPqkSBCTZuMnDSaiXSOTEV3zRq2UUNZN/OsCqqocQ=; b=iUm7uTf7vAPxgNBLsowolgag5l BHtF47DJPqbcwuJgzSs/FJwBJ8Awdp0W6p98DBM2ILxDaMGJXIMbotWZHzHCOm+bN6bduG+7xNamE AIunlGyAMoE78R8UBPUkVkCdW; Received: from 97-122-77-73.hlrn.qwest.net ([97.122.77.73]:43270 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from ) id 1qwSXW-002vRE-13; Fri, 27 Oct 2023 13:30:38 -0600 From: Tom Tromey To: Andrew Burgess Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 1/2] gdb: move all bfd_cache_close_all calls in gdb_bfd.c References: X-Attribution: Tom Date: Fri, 27 Oct 2023 13:30:37 -0600 In-Reply-To: (Andrew Burgess's message of "Wed, 25 Oct 2023 16:08:17 +0100") Message-ID: <87o7gjlv6q.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 97.122.77.73 X-Source-L: No X-Exim-ID: 1qwSXW-002vRE-13 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 97-122-77-73.hlrn.qwest.net (murgatroyd) [97.122.77.73]:43270 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Org: HG=bhshared;ORG=bluehost; X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-CMAE-Envelope: MS4xfFRXXaievUKy/s9vxEMBVweHJXihFMyKYK+Qh0y4LRFqtGTWPCQBGxh7o6vfV4etOJpkgnHlEL5C1eSzFrMSUJU1FMS2fg8dStWEZj5NdRQ9zSHeoltk TMSYKyUUCXXzjJyM5zq4qmT3oCbZvCaEOND5D/g+XibE9+5KaZZ1wmPuBnUGQ5FANX7C1/9lYVv9zjZ5CdyOWcGUw0zbrhrFLZc= X-Spam-Status: No, score=-3018.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,JMQ_SPF_NEUTRAL,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: >>>>> "Andrew" == Andrew Burgess writes: Andrew> Better I think would be to track down where the bfd is being opened Andrew> and add a corresponding bfd_cache_close_all() call elsewhere in GDB Andrew> once we've finished doing whatever it is that caused us to open the Andrew> bfd in the first place. I had contemplated this solution as well, though using bfd_cache_close on the specific BFD, instead. Like you point out, though, it seems finicky to get right. We could move up the call chain and add the close calls at some higher level, but even that seems hard to be assured of. Andrew> (a) Just before we display a GDB prompt. We display a prompt after Andrew> completing a command, and GDB is about to enter an idle state Andrew> waiting for further input from the user (or in async mode, for an Andrew> inferior event). If while we are in this idle state the user Andrew> changes the on-disk file(s) then we would like GDB to notice this Andrew> the next time it leaves its idle state, e.g. the next time the user Andrew> executes a command, or when an inferior event arrives, Andrew> (b) When we resume the inferior. In synchronous mode, resuming the Andrew> inferior is another time when GDB is blocked and sitting idle, but Andrew> in this case we don't display a prompt. As with (a) above, when an Andrew> inferior event arrives we want GDB to notice any changes to on-disk Andrew> files. I've been working on moving DWARF reading to the background. For the most part, your plan won't be an issue -- gdb pre-reads the relevant section data on the main thread and doesn't require the BFD to be open when scanning. However, there is one case where this will change: opening dwo files. Now, the way the background reading is implemented, the worst case here is some inefficiency: the main thread might close all the BFDs, and then the background reader might immediately reopen one. Maybe this isn't something to worry about? I could make the background reader also call bfd_cache_close for the DWO BFDs, to ensure they are closed. (This only really matters for the "rebuild" case, not any sort of exec case, because DWOs aren't really part of the inferior.) Andrew> Right now, the only other users of the observers that I'm connecting Andrew> too are the extension languages, specifically, Python. I suspect it Andrew> must be possible for Python to carry out actions that can cause the Andrew> bfd cache to be populated, so maybe there is a risk here. Andrew> To counter this risk, we could move the bfd_cache_close_all() calls Andrew> out of observers, and move them into GDB core close too, but after the Andrew> two observers in questions are actually called, so into Andrew> top_level_prompt for the before_prompt observer and into Andrew> notify_target_resumed for the target_resumed observer. Andrew> Another choice would be to add a bfd_cache_close_all() into Andrew> gdbpy_enter::~gdbpy_enter, so whenever we call into a Python Andrew> extension, we always clear the bfd cache once we're done. Andrew> For now I haven't made either of these changes, maybe I'm worrying Andrew> about nothing? I'd appreciate peoples thoughts. Do we know of specific Python APIs that could cause problems? I guess anything that reads memory if trust-readonly-sections is enabled? That's the only one I could think of offhand. Maybe we need a combo approach where some calls call bfd_cache_close at the end. Tom