From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 1F66A3858C52 for ; Thu, 14 Sep 2023 15:49:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1F66A3858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1694706574; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=79qVqA35z9ttUoVUWgcxoaDrgq1cKEQSrPBt2ONfm20=; b=FGFMg3Mk+wac+UwbFwlLHE48j+cKNW77k0O9EpmuqKlpWJIIGcty9p518nmeFNUQRniBfD MdXwkJUJTmK8RcrhyiUB4FviXuCWqior0RM0bA8KeNn/fRHcXvebNLkPH/uM36DeCOg/eN TU0k7dxewDlM0MhiSUEQw4eDDlUtbqg= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-694-SIGD-MeCOxWObWr2YOnZ-A-1; Thu, 14 Sep 2023 11:49:33 -0400 X-MC-Unique: SIGD-MeCOxWObWr2YOnZ-A-1 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-40298cbbcdbso8744425e9.3 for ; Thu, 14 Sep 2023 08:49:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694706572; x=1695311372; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=79qVqA35z9ttUoVUWgcxoaDrgq1cKEQSrPBt2ONfm20=; b=VZh5hPTv4qaelYyoe/5Md4cgPKwC6W1Tc3zTIZrWYFN9R8gyZF0b14KDA9liFsXyx6 JgCihZuQs1V21kgmGXSydx8Yps0Gceta4NB+F4N37Yk/VRLOzjxnv3poakDGeC+xrgQc iRGd7Hg2l57IivGbx8zPBqU8isd3J4H6u4Vg9w0O5+LaH+zVZ85CcVKwxVz4yOdnSPyu CwrZr9k9isMJ6tqqXhJXIwFEL6y33s68EGMaD9+nfo+90DxTQVgpQWMLwBFIAnB7hqvm jSoQ2nRsC2yANo0t6F19Nr66rLEU+j2bVsb19a4tZbzm3MfZDC7VqWirHuD7VyeNVT6/ IniA== X-Gm-Message-State: AOJu0Yx+FTeNmSGt918Qw0wUraUrZCI3/iu43TdEcvpi4J6W1Qtf3pHh 7skEu/AaQ7bGDM+3pjTLKmvYYRVY57s+WBmEVTu9xvZLvN479m533dta+a97tYOPbkPc+zbpNWq zra2s+bQTKB3nH6A+soTU+xjHRDN5xxVs92cg/grxUjYQfyKQoC1jJO3E5ZNBYu2AFblrQTjae3 9Zbq5o4Q== X-Received: by 2002:a7b:c7d4:0:b0:3fe:d57e:d933 with SMTP id z20-20020a7bc7d4000000b003fed57ed933mr5120090wmk.15.1694706572330; Thu, 14 Sep 2023 08:49:32 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFun+zznVR0BBpgSmXdzLPrfSP3CYPiBZnz2pvfBDvUQ78LqZlMPBfxX0RqXAzxEMgpysJ5xg== X-Received: by 2002:a7b:c7d4:0:b0:3fe:d57e:d933 with SMTP id z20-20020a7bc7d4000000b003fed57ed933mr5120073wmk.15.1694706571926; Thu, 14 Sep 2023 08:49:31 -0700 (PDT) Received: from localhost (197.126.90.146.dyn.plus.net. [146.90.126.197]) by smtp.gmail.com with ESMTPSA id e20-20020a05600c219400b003fe1c332810sm5142313wme.33.2023.09.14.08.49.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Sep 2023 08:49:31 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCH] gdb: small cleanup in symbol_file_add_with_addrs Date: Thu, 14 Sep 2023 16:49:29 +0100 Message-Id: <6219a1ae148c0b9796f7153b9a6c3b7173fb8f5a.1694706545.git.aburgess@redhat.com> X-Mailer: git-send-email 2.25.4 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: While looking at how gdb::observers::new_objfile was used, I found some code in symbol_file_add_with_addrs that I thought could be improved. Instead of: if (condition) { ... return; } ... return; Where some parts of '...' identical between the two branches. I think it would be nicer if the duplication is removed, and we just use: if (!condition) ... to guard the one statement that should only happen when the condition is not true. There is one change in this commit though that is (possibly) significant, there is a call to bfd_cache_close_all() that was only present in the second block. After this commit we now call that function for both paths. The call to bfd_cache_close_all was added in commit: commit ce7d45220e4ed342d4a77fcd2f312e85e1100971 Date: Fri Jul 30 12:05:45 2004 +0000 with the purpose of ensuring that GDB doesn't hold the BFDs open unnecessarily, thus preventing the files from being updated on some hosts (e.g. Win32). In the early exit case we previously didn't call bfd_cache_close_all, with the result that GDB would continue to hold open some BFD objects longer than needed. After this commit, but calling bfd_cache_close_all for both paths this problem is solved. I'm not sure how this change could be tested, I don't believe there's any GDB (maintenance) command that displays the BFD cache contents, so we can't check the cache contents easily. Ideas are welcome though. --- gdb/symfile.c | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/gdb/symfile.c b/gdb/symfile.c index 1b46ec45f2e..c20c0c50b9a 100644 --- a/gdb/symfile.c +++ b/gdb/symfile.c @@ -1119,18 +1119,13 @@ symbol_file_add_with_addrs (const gdb_bfd_ref_ptr &abfd, const char *name, time. */ gdb_flush (gdb_stdout); - if (objfile->sf == NULL) - { - gdb::observers::new_objfile.notify (objfile); - return objfile; /* No symbols. */ - } - - finish_new_objfile (objfile, add_flags); + if (objfile->sf != nullptr) + finish_new_objfile (objfile, add_flags); gdb::observers::new_objfile.notify (objfile); bfd_cache_close_all (); - return (objfile); + return objfile; } /* Add BFD as a separate debug file for OBJFILE. For NAME description base-commit: d7680f13df105aa8fa0edbdf8efae31a5411f579 -- 2.25.4