From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id W33LCXpkT2EJYgAAWB0awg (envelope-from ) for ; Sat, 25 Sep 2021 14:03:38 -0400 Received: by simark.ca (Postfix, from userid 112) id 001AA1EE25; Sat, 25 Sep 2021 14:03:37 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=MAILING_LIST_MULTI, RDNS_DYNAMIC autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id B8DD21EE14 for ; Sat, 25 Sep 2021 14:03:36 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0E521385840D for ; Sat, 25 Sep 2021 18:03:36 +0000 (GMT) Received: from zeniv-ca.linux.org.uk (zeniv-ca.linux.org.uk [IPv6:2607:5300:60:148a::1]) by sourceware.org (Postfix) with ESMTPS id 42E133858403; Sat, 25 Sep 2021 18:02:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 42E133858403 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=ftp.linux.org.uk Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mUC0g-007HJ0-Gg; Sat, 25 Sep 2021 18:02:50 +0000 Date: Sat, 25 Sep 2021 18:02:50 +0000 From: Al Viro To: Rustam Kovhaev Subject: Re: [RFC][PATCH] coredump: save timestamp in ELF core Message-ID: References: <20210925171507.1081788-1-rkovhaev@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210925171507.1081788-1-rkovhaev@gmail.com> X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, gdb-patches@sourceware.org, binutils@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On Sat, Sep 25, 2021 at 10:15:07AM -0700, Rustam Kovhaev wrote: > Hello Alexander and linux-fsdevel@, > > I would like to propose saving a new note with timestamp in core file. > I do not know whether this is a good idea or not, and I would appreciate > your feedback. > > Sometimes (unfortunately) I have to review windows user-space cores in > windbg, and there is one feature I would like to have in gdb. > In windbg there is a .time command that prints timestamp when core was > taken. > > This might sound like a fixed problem, kernel's core_pattern can have > %t, and there are user-space daemons that write timestamp in the > report/journal file (apport/systemd-coredump), and sometimes it is > possible to correctly guess timestamp from btime/mtime file attribute, > and all of the above does indeed solve the problem most of the time. > > But quite often, especially while researching hangs and not crashes, > when dump is written by gdb/gcore, I get only core.PID file and some > application log for research and there is no way to figure out when > exactly the core was taken. > > I have posted a RFC patch to gdb-patches too [1] and I am copying > gdb-patches@ and binutils@ on this RFC. > Thank you! IDGI. What's wrong with the usual way of finding the creation date of any given file, including the coredump one?