From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) by sourceware.org (Postfix) with ESMTPS id 0B5763858C52 for ; Thu, 28 Sep 2023 18:15:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0B5763858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com Received: by mail-il1-x12b.google.com with SMTP id e9e14a558f8ab-351367c8fcdso27683455ab.3 for ; Thu, 28 Sep 2023 11:15:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1695924920; x=1696529720; darn=sourceware.org; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=HKjq0Krk8HhhlFlekqN/c8vHI8l8BiL21pEfjvbXMYc=; b=YBHOxttTE0lCYXHYhMe0NJ14n1rnXM1JTOLhGuQL0lKyxlhMCoe+Kuq2kQw1pyiEGP 1yLqEGZltLD8Nq/nt4qj9vJch0XDwcj0GnFkwbkAo4kQIZoKRZJsMn09wRp4LBP+lRmh LpPE35qgPlsDJxAHX8S7XSstqmNr5IETo2lcJOwsLHBy9V0Y7w0Pu660NxxCI7tCIfKH ilqt5CernN//WYOcykKuNEr9zx98gqa01uBk+y8R7OShrRAovPdT+lnaduHJmMj5I7kj KLwsSMYkCOhzdwz+Cta7+lkxesmJdNq6MiEVKaUwUxgTBPTR8MCQRZ0PiwKkZyXDp+s6 O94g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695924920; x=1696529720; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=HKjq0Krk8HhhlFlekqN/c8vHI8l8BiL21pEfjvbXMYc=; b=JCmq/1KKahgGKQGxqm+3xKq3dqp8uXQehhIUE9i78E+iGKDcq8hCfRsOaS4rf70qlx qg+WG3VUZgqaTOJXxc9qbriuOm3E5SJbNH5oM8QHQ2e7H8i/We09WcmCmZycg136ouQA TNqC2lcnJ08+CMEQRizkWXDduoRlWJhZSU6oTYatSRJX9zJYV+ffjGTFhYJGfVS184lY JqVCPDcp3kGx8C8OS9zVHLC0RA5aewWs2owvbZ/cxDg4vSfynHuBb+vDIdJWUeD/DEPk tXh7ggt2I2AdkvvtwQ4WzG/hgzEaLOEvxi4wAWjmym2MszvMikaN4ltEqp/k2TRSHqEC JNQA== X-Gm-Message-State: AOJu0YyaifAkkCIgMSXfCXhYSegmhThBLi5d1lOblKN02bVqolHmsjfR ZS1l/wzoO27i1n0XrMf0ink17Q== X-Google-Smtp-Source: AGHT+IEl7i56oDfMSxVIndENON72N6GFyu/GQ/p+P47P28J2PzoCOEkhWxdJQnbIImDnUKs3YJCqtQ== X-Received: by 2002:a05:6e02:c62:b0:351:a18:51be with SMTP id f2-20020a056e020c6200b003510a1851bemr1667781ilj.15.1695924920346; Thu, 28 Sep 2023 11:15:20 -0700 (PDT) Received: from murgatroyd (71-211-130-31.hlrn.qwest.net. [71.211.130.31]) by smtp.gmail.com with ESMTPSA id x14-20020a056e020f0e00b0035134215863sm3382699ilj.55.2023.09.28.11.15.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Sep 2023 11:15:19 -0700 (PDT) From: Tom Tromey To: Andrew Burgess Cc: Tom Tromey , Andrew Burgess via Gdb-patches Subject: Re: [PATCH 9/9] gdb: use reopen_exec_file from reread_symbols References: <87msxi8dcv.fsf@tromey.com> <877coawcd9.fsf@redhat.com> X-Attribution: Tom Date: Thu, 28 Sep 2023 12:15:18 -0600 In-Reply-To: <877coawcd9.fsf@redhat.com> (Andrew Burgess's message of "Thu, 28 Sep 2023 16:23:14 +0100") Message-ID: <87msx62mh5.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-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: >>>>> "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". Tom