From nobody Tue Nov 23 09:11:03 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6087D1891954 for ; Tue, 23 Nov 2021 09:11:06 +0000 (UTC) (envelope-from mgorny@moritz.systems) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hyyzt200Bz4vcH for ; Tue, 23 Nov 2021 09:11:06 +0000 (UTC) (envelope-from mgorny@moritz.systems) Received: by mail-lf1-x133.google.com with SMTP id b40so89488503lfv.10 for ; Tue, 23 Nov 2021 01:11:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moritz-systems.20210112.gappssmtp.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=2vQoPz6+uhjR4ljrW1qRvHTdFxLJ1a/GL9HNqkhbtQU=; b=CIl2FZs95CCEc82+cRAkkp/T5Fr7azcBBJ/G+oy0NDPUKfqjchEZ1ccco/of5cFpTm PJgzlwC09P807dZmc0tz2l8r7EpeHyYC9b0NZmN6pBctdj1nNHla55QmowaBkhNXAo0k cQLaFy+e0miuxrrjd/Kdo6jPojEZIEz/BwWHLrTnRt0J6E9ecbXQXGG5eRqC9I+RKbP9 RFeQKLWVNBySiJuP93ARyQQa9Bkmszud6gwVhAXrmarxjZ1kZ0tHB464vbrTxVABM8uZ ao6uKK8IYtbLUdSjORCocifhp5xvbyQV09TvBVu8GCAOt/u219GEmtwNvNdhJRfjOlb3 I/IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=2vQoPz6+uhjR4ljrW1qRvHTdFxLJ1a/GL9HNqkhbtQU=; b=gJiUtab4xsbVSDqlQIDlj625fGllybFCESjPaSdIvCRUMG7ia5vaIOHdXoA9wHnFhR RiM1/Ib+Ng8AvkdcYZN1yypnSZ5eU4H9cixRhVh0Cwl0lvKwCRuQF4jxxNhTGgeOL9uA +rpV5qaTsbCFYPBH5vAKdr64ZKIJ9AdedGOUb/3W2ztv31r0REiwO/fYdYz9B/lu0QR0 dNHUcvkNDWWKL/mF5Qo10caIZWa2N5C8Zrhjf5Cg1pGkrq5JDgh8yHYlCSAGzSqPesWe We1aXqWQqQyKCE+pxfLPBswrB+30MfIfn4LS4QrEOi29tbxwTwfGJJ1f59sr7obHAUGU 1mbg== X-Gm-Message-State: AOAM532eVrTbOCxbv5PIpIevvL75rTVjfr6RXIp9cwl+2bXepoiN1M6U rigHOiqQXKPXg3V6GAi6EDe094xdkyRDrw== X-Google-Smtp-Source: ABdhPJwL8762OWG3/vJRwNzsFVUEfEIfzelsFXMJs1amMlTUbR3oSJNl9BCs6ANSz2TMqhHzx1FfEw== X-Received: by 2002:a05:6512:70a:: with SMTP id b10mr3228132lfs.32.1637658664716; Tue, 23 Nov 2021 01:11:04 -0800 (PST) Received: from [192.168.1.12] (c139-65.icpnet.pl. [85.221.139.65]) by smtp.gmail.com with ESMTPSA id 27sm1226432lft.299.2021.11.23.01.11.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Nov 2021 01:11:04 -0800 (PST) Message-ID: <4b1b49da6c83165fbad3c4804c1394473e1b67da.camel@moritz.systems> Subject: Re: Looking for rationale for the minidump format From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: John Baldwin , freebsd-hackers@FreeBSD.org Cc: emaste@FreeBSD.org, peter@FreeBSD.org Date: Tue, 23 Nov 2021 10:11:03 +0100 In-Reply-To: References: <305082d9f216bb8382773c074eaf7a5c3101cc13.camel@moritz.systems> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Hyyzt200Bz4vcH X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, 2021-11-22 at 09:47 -0800, John Baldwin wrote: > On 11/21/21 6:42 AM, Michał Górny wrote: > > Hi, everyone. > > > > As part of the work contracted by the FreeBSD Foundation, I'm working > > on adding explicit minidump support to LLDB. When discussing > > the options with upstream, I've been asked why FreeBSD created their own > > minidump format. > > > > I did a bit of digging but TBH all the rationale I could get was to > > create partial memory dumps. However, unless I'm mistaken the ELF > > format is perfectly capable of that -- e.g. via creating an explicit > > segment for every continuous active region. > > > > Does anyone happen to know what the original rationale for creating > > a custom file format was, or know where to find one? Thanks in advance. > > The direct map aliases pages mapped via kmem. You'd be double dumping > all the data mapped into kmem, once for the direct map and once for the > non-direct mappings. > > You can think of minidumps as being a dump of physical memory, whereas > an ELF core for a virtually-mapped kernel wants to dump virtual memory, > and there is the disconnect. > > [...] > > You could perhaps imagine something similar where you had an ELF core > with physical memory for PT_LOAD instead of virtual and a way to hint that > so that the debugger would handle all the virtual -> PA translation, but > you'd still need some home-grown notes for some of the other metadata we > pass along (like the message buffer, etc.). Also, changing the format > doesn't help with reading existing crash dumps. > Thank you for your reply. If I understand correctly, you're comparing minidump with a "proper" (i.e. virtual memory-based) ELF core. However, the "full memory dump" ELF core also uses physical memory map model, is that correct? Does that mean that using a different core format makes it clear that it's a physical memory dump and not virtual? That said, please correct me if I'm mistaken but I think we should be able to create a "virtual memory mapped" ELF core without too much duplication. We could creating multiple segments with different p_vaddr values but the same file p_offset, correct (and maybe p_paddr)? I'm not advocating for changing the format, just trying to improve my knowledge. -- Best regards, Michał Górny