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 0FFEF3858C78 for ; Fri, 29 Sep 2023 10:17:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0FFEF3858C78 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=1695982637; 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: in-reply-to:in-reply-to:references:references; bh=qi2iTbl2UiX+f67FT6NHo5jJW1art1sZg3EwPkMp1Ts=; b=Tfb4Ukgm/k8JjCPPXq1o20oCyEWo4GcBPQnsswEfuRW6qg3AhtXr6HGyfuTwPdCd/bGl4m Y3r9d5Mtwixldp5hw45TSQwNxLaTTcMkP/ROOJweXEpzMiCwhX1VIW5hVyoPDaDOOWOAbl 4f00h+nShLqicG0eXbIiHfxbZ21/Cxs= Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-126-AozitCEROkSS3-zSYK1kbg-1; Fri, 29 Sep 2023 06:17:16 -0400 X-MC-Unique: AozitCEROkSS3-zSYK1kbg-1 Received: by mail-ej1-f72.google.com with SMTP id a640c23a62f3a-9ae0bf9c0a9so1171303266b.3 for ; Fri, 29 Sep 2023 03:17:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695982635; x=1696587435; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qi2iTbl2UiX+f67FT6NHo5jJW1art1sZg3EwPkMp1Ts=; b=fKbaA2+VyYUPMy1QdjvlbBsKTVHxASWn7LO5aLK7LDRw8AzxeyNHd4vwoOtJmw/yWq TU/947YuDvta3E938gYk+8zYulcBw5lSDmwWx04KBmKuHlaupUyhUYL8Tzo5Fok9Lx45 T5FJKvwr9wvQEsWU6cX8xnyaQ6cCNSAVNl3CDEfv3yY3i/GtJGC8AYCeZVQ7I+30WXoM abmE5e0bFZonS5PqGKkXc+DJkpc4CRAnu4vtvy2R+hpYNY5riel+axJgS4AK5Zx4he9J GvXN7FiJ3XNVvllYcEH4s+nBIcT6gH4AKO/RfMo/Sr1RVOiCbItEptpcqiz3EtH5rDrb ue7A== X-Gm-Message-State: AOJu0Yz6yVcdYK87CBNugaiVH77RMq5ucm4WIFeAQwZhIXgBie8RcjyQ 4FhsRa34uxKfFpeynIUMLm4PbbKQszdVRQfh8V9GHCY627ha7cAYL3vRcFeigosy5IhjXb/Ii3B M/qK7s1PN4gwD7eM3HndZgICOoPINpQ== X-Received: by 2002:a17:906:23e9:b0:9aa:1c70:1654 with SMTP id j9-20020a17090623e900b009aa1c701654mr3350379ejg.54.1695982635108; Fri, 29 Sep 2023 03:17:15 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFbLVB6JMCPwx10JDriyBiUo03NdK2hRVvTxxo+6kv92Ce+yZGee4cdzGjqtt9RzGiJkd/gvA== X-Received: by 2002:a17:906:23e9:b0:9aa:1c70:1654 with SMTP id j9-20020a17090623e900b009aa1c701654mr3350365ejg.54.1695982634741; Fri, 29 Sep 2023 03:17:14 -0700 (PDT) Received: from localhost ([31.111.84.209]) by smtp.gmail.com with ESMTPSA id gq23-20020a170906e25700b009ad75d318ffsm12343206ejb.17.2023.09.29.03.17.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Sep 2023 03:17:14 -0700 (PDT) From: Andrew Burgess To: Tom Tromey Cc: Tom Tromey , Andrew Burgess via Gdb-patches Subject: Re: [PATCH 9/9] gdb: use reopen_exec_file from reread_symbols In-Reply-To: <87msx62mh5.fsf@tromey.com> References: <87msxi8dcv.fsf@tromey.com> <877coawcd9.fsf@redhat.com> <87msx62mh5.fsf@tromey.com> Date: Fri, 29 Sep 2023 11:17:12 +0100 Message-ID: <87sf6xuvvb.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: Tom Tromey writes: >>>>>> "Andrew" == Andrew Burgess writes: > > Andrew> I didn't fully understand all the discussion w.r.t. gnulib stat vs > Andrew> system stat, but I'm hoping the change above, which is less that your > Andrew> originally proposed full change, might be mergable. > > FTR (and IIUC) the issue is that gnulib's stat yields different times on > Windows hosts, because it tries to handle the timezone -- on Unix, stat > reports in UTC, but on Windows it may report in local time. > > The result is that BFD will report times that are offset from the times > reported by gnulib. > > gnulib doesn't provide a way to change this behavior, so one proposal in > the thread was to hack gnulib. > >>> I don't think gdb has a very clear idea of when bfd_cache_close_all >>> ought to be called. > > Andrew> I agree this stuff doesn't seem well defined at all, but I don't think I > Andrew> made anything particularly worse in this respect, so I'm leaving that as > Andrew> a problem for the future. > > One thing I wonder is whether bfd_cache_close_all is even needed. > gdbserver doesn't do this and AFAIK, gdb just keeps all those remote fds > open. > > Maybe we're missing some testing scenario, though, like gdbserver > extended-remote with "gdb --write". So, I touched a bfd_cache_close_all recently[1], and dug into the history of these calls a little at the time. They were first added to GDB in this commit: commit ce7d45220e4ed342d4a77fcd2f312e85e1100971 Date: Fri Jul 30 12:05:45 2004 +0000 Before this there were no bfd_cache_close_all calls in the GDB tree. The mailing list thread associated with this commit is: https://sourceware.org/pipermail/gdb-patches/2004-July/036407.html Though this thread seems to reference some older thread that I've not been able to track down. The above thread is titled: [RFA] win32: bfd_cache_close after kill 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. 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. Having a bfd_cache_close_all call in e.g. reopen_exec_file, seems pretty pointless really, as it's not impossible that GDB will then immediately re-open the BFD from some other function. I wonder if we should remove all bfd_cache_close_all calls, and just have two calls associated with the two states above? [1] https://inbox.sourceware.org/gdb-patches/6219a1ae148c0b9796f7153b9a6c3b7173fb8f5a.1694706545.git.aburgess@redhat.com/ Thanks, Andrew