From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 05AD93858405 for ; Tue, 24 Aug 2021 13:50:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 05AD93858405 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 17ODoP0d006883 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Aug 2021 09:50:30 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 17ODoP0d006883 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 017631E4A3; Tue, 24 Aug 2021 09:50:24 -0400 (EDT) Subject: Re: Executing code if debuggee is a crash dump? To: Michael Woerister , gdb@sourceware.org References: From: Simon Marchi Message-ID: <405ba691-bac2-8eb4-aa8c-ec13ef59fceb@polymtl.ca> Date: Tue, 24 Aug 2021 09:50:24 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Tue, 24 Aug 2021 13:50:25 +0000 X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 13:50:50 -0000 On 2021-08-24 6:07 a.m., Michael Woerister via Gdb wrote:> Hi everyone, > > I'm looking into implementing debugger extensions that help with debugging crash dumps of "async" Rust executables. Such an extension would need to inspect the complex internals of several async runtime implementations. We could potentially make the extension more robust and easier to maintain if we provided a standardized inspection API in the various runtimes and have the debugger interact with that. The functions behind this API would be restricted to not interact with the environment (e.g. not allocate memory, etc). > > However, my research so far indicates that neither GDB nor any other debugger is capable of executing code in a crash dump. Is that true or am I overlooking something? > Would anybody here be able give me a definite answer to this question? > > Thanks a lot for your help! > > -Michael > Hi Michael, Indeed, when inspecting a crash dump in GDB, there's no live process, so you can't do function calls in it. That's one of the downsides of relying on function calls to build pretty printers and other tools that extract data from debugged programs. I've sometimes heard the idea of creating a live process from a crash dump state, but I have never seen it implemented. In theory, if that existed, that would allow you to do function calls. But there is some state that can't really be restored, like file descriptors, so that limits what you can do. Another downside of that is that you wouldn't be able to inspect a core dump on a different architecture than what the core dump was created on (something that is useful for embedded devices). So people often end up using some GDB / Python code that has the knowledge of the program's internal data structures. For example, the Linux kernel: https://github.com/torvalds/linux/blob/master/scripts/gdb/vmlinux-gdb.py Simon