From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11537 invoked by alias); 17 Oct 2014 11:24:13 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 11511 invoked by uid 89); 17 Oct 2014 11:24:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e06smtp13.uk.ibm.com Received: from e06smtp13.uk.ibm.com (HELO e06smtp13.uk.ibm.com) (195.75.94.109) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 17 Oct 2014 11:24:09 +0000 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 17 Oct 2014 12:24:05 +0100 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 17 Oct 2014 12:24:03 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 0F547219004D for ; Fri, 17 Oct 2014 12:23:40 +0100 (BST) Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id s9HBO39L7668134 for ; Fri, 17 Oct 2014 11:24:03 GMT Received: from d06av01.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s9HBO23h018280 for ; Fri, 17 Oct 2014 05:24:03 -0600 Received: from br87z6lw.de.ibm.com (dyn-9-152-212-196.boeblingen.de.ibm.com [9.152.212.196]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s9HBO17A018249; Fri, 17 Oct 2014 05:24:02 -0600 From: Andreas Arnez To: "Discussion list for crash utility usage\, maintenance and development" Cc: GDB Development Subject: Re: gdb on KDUMP files References: <20141002102700.3eba84a5@suse.cz> Date: Fri, 17 Oct 2014 11:24:00 -0000 In-Reply-To: <20141002102700.3eba84a5@suse.cz> (Petr Tesarik's message of "Thu, 2 Oct 2014 10:27:00 +0200") Message-ID: <87d29rhrce.fsf@br87z6lw.de.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14101711-0013-0000-0000-0000017CAC3E X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00061.txt.bz2 Petr, I'm copying the GDB mailing list, because this is probably of interest to the GDB community as well. On Thu, Oct 02 2014, Petr Tesarik wrote: > On Thu, 2 Oct 2014 03:18:55 +0000 > Pete Delaney wrote: > >> Hi: >> >> Six years ago Dave and I were discussing using gdb on KDUMP files: >>[...] >> >> Anyone know what's going on? > > [...] > > I'm glad you're interested in using GDB to read kernel dump files, > especially if you're willing to make it work for real. I have proposed > more than once that the crash utility be re-implemented in pure gdb. Incidentally, I've tossed this idea around as well. Do you have a pointer to one of these proposals (and discussions, if any)? > Last time I looked (approx. 1.5 years ago) the main missing pieces were: > > 1. Use of physical addresses (described above) I guess this includes the capability to translate virtual to physical addresses, using the kernel's page tables? > 2. Support for multiple virtual address spaces (for different process > contexts) One way of dealing with this might be to represent the different virtual address spaces as multiple inferiors. > 3. Ability to read compressed kdump files > 4. Ability to use 64-bit files on 32-bit platforms (to handle PAE) In addition, there might be: 5. Support kernel modules and represent them as "shared objects". 6. Understand the kernel's task structures. Represent multiple tasks within the same "inferior" as threads in GDB. 7. Format functions: Extract information from kernel data structures and show it in a digested, more readable, form. Perhaps such functions can be implemented as Python scripts. Among others, I'd envision the following GDB commands: file Specify vmlinux Elf image target kdump Load kdump info sharedlibrary List kernel modules info inferiors List address spaces ("processes") inferior Switch to certain address space info threads List threads in current address space bt, up, down, frame Usual behavior generate-core-file Write core dump for the current inferior linux cmdline Show kernel command line linux kmesg Show kernel message buffer linux cpuinfo List CPUs and their state linux ... Other format functions All of this together may not be a small task, and there are still various open questions, e.g. how to deal with interrupt contexts. But I think we could already provide useful functionality with a smaller initial development stage and defer features like multiple address space support, PAE support, format functions, etc., to a later stage. -- Andreas