From nobody Mon Nov 22 17:47:42 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 66ACF188A5E2 for ; Mon, 22 Nov 2021 17:47:44 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HyZVS2WS4z4l4G; Mon, 22 Nov 2021 17:47:44 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id B9A53973B; Mon, 22 Nov 2021 17:47:43 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Mon, 22 Nov 2021 09:47:42 -0800 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 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-US To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= , freebsd-hackers@FreeBSD.org Cc: emaste@FreeBSD.org, peter@FreeBSD.org References: <305082d9f216bb8382773c074eaf7a5c3101cc13.camel@moritz.systems> From: John Baldwin Subject: Re: Looking for rationale for the minidump format In-Reply-To: <305082d9f216bb8382773c074eaf7a5c3101cc13.camel@moritz.systems> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N 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. There are somewhat similar issues with talking to bare metal stubs that insist on always using physical addresses (e.g. openocd talking to RISC-V FPGA soft cores). For that I have theorized (but not implemented) adding a new qXfer (or the like) for physical memory and a way to negotiate that a target only supports physical addresses as part of qSupported and then having logic in the arch-dependent code (riscv-tdep.c in gdb, not sure what the equivalent layer would be in lldb) to handle translation of virtual addresses to physical before reading physical memory (e.g. on RISC-V it would be sufficient to expose the $satp register from the remote stub). 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. You could also perhaps depend on ELF register notes for thread state vs enumerating threads (which might be nice), but you'd still have to duplicate all of that logic to handle talking to remote baremetal stubs like QEMU / bhyve where the threads exposed via the remote protocol are vCPUs, not kernel threads, so that doesn't really save you any work in the debugger in the end. -- John Baldwin