From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id hihDLFlsT2HRYgAAWB0awg (envelope-from ) for ; Sat, 25 Sep 2021 14:37:13 -0400 Received: by simark.ca (Postfix, from userid 112) id A3E521EE25; Sat, 25 Sep 2021 14:37:13 -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.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED 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 D72E21EE14 for ; Sat, 25 Sep 2021 14:37:12 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 17D7C3858416 for ; Sat, 25 Sep 2021 18:37:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 17D7C3858416 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1632595032; bh=MIOL2DZ31awChihosWu8oRBkY3Cg7xqjslUJhnt/4eU=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=gUxQ1AlEqPvG0djLRAxtSxz24BSx8TyAJXqdZNqI02YQJVkJ6Qi2GCAglDf7BmhrB qjn98eLRkz+AWkBg9nEZTSuAumpwUlqACmbdHzWJifZlNa7IxsoLvREdPe9iBE7wWo 1J2zEiqI89u4PQ0mUOUbF/gX6Ri98zv+V9sUckdc= Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) by sourceware.org (Postfix) with ESMTPS id D6CBD3858403; Sat, 25 Sep 2021 18:35:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D6CBD3858403 Received: by mail-pg1-x530.google.com with SMTP id 17so13330847pgp.4; Sat, 25 Sep 2021 11:35:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=MIOL2DZ31awChihosWu8oRBkY3Cg7xqjslUJhnt/4eU=; b=CM5amqDgeZGRY6adBrYcQmFeMVxl9+2b9BOwsjbu6DGWERsORGhxI351v01WJFnZYh +1nHx1ifYdF4Tm0C8OQz2NrAazs+jH/+VDrlexFuzrAVhvV8zGzYxFU6hmXj4iI8WYKL uEWJcwfjWPDbJIdpxofIoi8kX/RVQUTWmX3AfSZ1A9v3B+WUHgxmUwmiEU/7mVtINtGM i+WecmUdGNuyLz5tQsdLha8dB2JM8JKMVprd0sxjTeS5oSJJMucCp5JCR+LY3mbRwP6m m9DohTagd0HBm01J5/lyyiooibriRExHWxWkP4+Tvx9N9n7eieafHbzbgRGQ5jifnSwg ePBA== X-Gm-Message-State: AOAM533ozWqJ4PqxdFK3l12fBJTwUx54mcKY4hpAIpEPAVPhTN9OIejK uRwQVM4GFU8UgJPOxaDRg4nKRuCSFS0KbiZS X-Google-Smtp-Source: ABdhPJy8mn0NcDitGa65lH16AjlnnmqxmP/T1zyetxFFMStFlB4BXGJH3Z0yXuK65ObbhjlBP4fdPw== X-Received: by 2002:a63:1352:: with SMTP id 18mr9047429pgt.348.1632594951825; Sat, 25 Sep 2021 11:35:51 -0700 (PDT) Received: from nuc10 (d50-92-229-34.bchsia.telus.net. [50.92.229.34]) by smtp.gmail.com with ESMTPSA id x8sm12622698pfq.131.2021.09.25.11.35.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 25 Sep 2021 11:35:51 -0700 (PDT) Date: Sat, 25 Sep 2021 11:35:49 -0700 To: Al Viro 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: 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: , From: Rustam Kovhaev via Gdb-patches Reply-To: Rustam Kovhaev 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 06:02:50PM +0000, Al Viro wrote: > 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? Sometimes file attributes get reset/modified when the file changes hands. Here is what usually happens: We ask customer to take a few cores of some hanging process, customer does so, then copies the files out from his Linux servers/machines, then creates an archive on his machine (usually windows/mac) and then, emails or uploads the archive, and, if we are lucky we get correct creation date of the core in the archive, but most of the time creation date gets reset/modified somewhere along this process.