From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) by sourceware.org (Postfix) with ESMTPS id A1C833858418 for ; Tue, 19 Sep 2023 14:08:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A1C833858418 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-io1-xd29.google.com with SMTP id ca18e2360f4ac-7927f36120cso199233139f.1 for ; Tue, 19 Sep 2023 07:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1695132514; x=1695737314; 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=/eIgWtRt2o2DuZPHeIAu0GXbzLojc3aYKTOUubd4qEE=; b=gKHjZWgmp9EIfpAlPKkSgeG0W3tU330zDoufAR/6Tira0Y/eV/74u6BdZiCpGXRQZF ZcC5tYZV1okJBskhVMjMcy0yWZAfl2kqvgvgZm1xr4n/XpNU0u+R2ivnDHftuRJSGJ2Y WJiVpKZvo3/W4WwQbT0d4XzDDTOOMEaQ0ndbhpQQ46DYcELPbPvwuqxLh+O8OGAEzz/Z +FFU+B+VwxSkczh/Z7tG/alafSR9uAHcGcf9drdv9QuA97njKnt+JGi6/Ci/0Ap+oqwV 3z5FTan4bh5QFnm5FDO+mPArOrguHUQD8T7wkc2Ng6pzGAJf8kbBcWMTskZqyaMyxLRT nFzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695132514; x=1695737314; 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=/eIgWtRt2o2DuZPHeIAu0GXbzLojc3aYKTOUubd4qEE=; b=d0sGb/LYKjnONlVxejqac/fGxBe1yGDmdgCgijYAsBV29XCY9BzzUAvAXc4/spNuDK X/TEL7yp3/vL2H8A2MW6dcV0jJsytWD3mR4jH5h+6zt9NGdyFx+VMdWrd2HwJX5wovxU ZRkpPI6tn/iUNqrUhVZJg57Tp8xRnJKEBFqJHljfyeHvs3AyT9785Z8wSucixgL9oUFg VYujlxK2OVy0f394pilHbugRWewgkMnTQBHtfy+wIuHtuFbzzezQT0JdzANqrjKfvrXT gAbA2WsuFMQif9D15dkmzh5zifuOF82qn08jZ3oZde36/unpNbdg2hDxNkH/Lgzs3Nvo +BtA== X-Gm-Message-State: AOJu0Yxf3dwXy9d7tXJYml9i7EZQuAtqeGtiTGxlyVdlEav2wWxcYWLZ ZVmh/lsjgRXy01J9bWdm258xIw== X-Google-Smtp-Source: AGHT+IHG/pZni+SRAJKN0txNcMwCjVGyPRPFAilYk7JIdNq+5yncVRavLNiKt31Hdgo3hNMQkrLuew== X-Received: by 2002:a92:c54c:0:b0:345:79eb:e001 with SMTP id a12-20020a92c54c000000b0034579ebe001mr16351035ilj.19.1695132513783; Tue, 19 Sep 2023 07:08:33 -0700 (PDT) Received: from murgatroyd (71-211-130-31.hlrn.qwest.net. [71.211.130.31]) by smtp.gmail.com with ESMTPSA id n27-20020a02cc1b000000b00430bb70004dsm3512807jap.103.2023.09.19.07.08.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Sep 2023 07:08:33 -0700 (PDT) From: Tom Tromey To: Andrew Burgess via Gdb-patches Cc: Andrew Burgess Subject: Re: [PATCH 9/9] gdb: use reopen_exec_file from reread_symbols References: X-Attribution: Tom Date: Tue, 19 Sep 2023 08:08:32 -0600 In-Reply-To: (Andrew Burgess via Gdb-patches's message of "Sat, 16 Sep 2023 11:18:10 +0100") Message-ID: <87msxi8dcv.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 via Gdb-patches writes: Andrew> + reopen_exec_file (); This addition could probably use a comment explaining why it is needed. Andrew> - new_modtime = new_statbuf.st_mtime; Andrew> + long new_modtime = new_statbuf.st_mtime; Might as well change this to time_t now. I don't really understand how reread_symbols interacts with target: files. It seems like this is just broken. At AdaCore we carry a patch that changes this code to use bfd_stat. According to internal notes, this was pushed: https://sourceware.org/legacy-ml/gdb-patches/2020-01/msg00386.html ... but I don't see it in gdb. Maybe we never resolved the 'stat' issue in gnulib? Anyway, the reason I bring this up is that reopen_exec_file calls bfd_cache_close_all -- but then the loop in reread_symbols, in the bfd_stat case, will reopen the files (BFD uses fstat). This seems unfortunate. I don't think gdb has a very clear idea of when bfd_cache_close_all ought to be called. It would be good to clear this up. I'm not very clear on it myself. Maybe it is to avoid ETXTBUSY errors -- in which case it seems like it should be called just before starting the inferior. But, ISTR some error on Windows as well, though I don't know exactly what... so maybe the files need to be guaranteed-closed in other situations as well. Tom