From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9972 invoked by alias); 10 Mar 2005 07:14:49 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 9444 invoked from network); 10 Mar 2005 07:14:15 -0000 Received: from unknown (HELO ebiederm.dsl.xmission.com) (166.70.28.69) by sourceware.org with SMTP; 10 Mar 2005 07:14:15 -0000 Received: from ebiederm.dsl.xmission.com (localhost [127.0.0.1]) by ebiederm.dsl.xmission.com (8.12.3/8.12.3/Debian-7.1) with ESMTP id j2A7BC9N021485; Thu, 10 Mar 2005 00:11:12 -0700 Received: (from eric@localhost) by ebiederm.dsl.xmission.com (8.12.3/8.12.3/Debian-7.1) id j2A7BAKt021482; Thu, 10 Mar 2005 00:11:10 -0700 X-Authentication-Warning: ebiederm.dsl.xmission.com: eric set sender to ebiederm@xmission.com using -f To: dipankar@in.ibm.com Cc: Andrew Morton , Dave Anderson , gdb , fastboot , lkml Subject: Re: [Fastboot] Re: Query: Kdump: Core Image ELF Format References: <1110286210.4195.27.camel@wks126478wss.in.ibm.com> <1110350629.31878.7.camel@wks126478wss.in.ibm.com> <20050309150644.GA4663@in.ibm.com> From: ebiederm@xmission.com (Eric W. Biederman) Date: Thu, 10 Mar 2005 07:14:00 -0000 In-Reply-To: <20050309150644.GA4663@in.ibm.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-03/txt/msg00094.txt.bz2 Dipankar Sarma writes: > On Wed, Mar 09, 2005 at 07:17:49AM -0700, Eric W. Biederman wrote: > > Beyond that I prefer a little command line tool that will do the > > ELF64 to ELF32 conversion and possibly add in the kva mapping to > > make the core dump usable with gdb. Doing it in a separate tool > > means it is the developer who is doing the analysis who cares > > not the user who is capturing the system core dump. > > Well, as a kernel developer, I am both :) For me, having to install > half-a-dozen different command line tools to get and analyze a crash dump > is a PITA, not to mention potential version mismatches. As someone > who would like very much to use crash dump for debugging, I would > much rather be able to force a dump and then use gdb for > a quick debug. I agree that a customer would see a different > situation. It would be nice if we can cater to both the kinds. Crash dumps seem to be a when all else fails kind of solution. Or something to make a detailed record of what happened so information can be logged. I think are differences are largely a matter of emphasis. I worry about the end user and the whole cycle. For that we need a fixed simple crash dump format whit no knobs bells or whistles, that can be given to developers and eventually supported natively by all of the tools. I doubt tweaking gdb so it can handle a 64bit ELF core dump even on 32bit architectures would be very hard. Once that is in place the 64->32bit conversion doesn't matter. The virtual addresses matter a little more although I am more inclined to teach gdb about the physical and virtual address differences of whole machine crash dumps. I do agree that the ability to tweak things in the short term to work like a process that does not have the virtual/physical address distinction is useful. The issue of tool versioning problems is bogus. That is solved by simply picking a good interface between tools and sticking with it. Occasionally there will be paradigm shifts (like threading) that will cause change, but generally everything will stay the same. In addition if tools are distributed together it does not matter, if there are several of them because there is only one update. Eric