From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16150 invoked by alias); 21 Oct 2014 05:53:20 -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 16138 invoked by uid 89); 21 Oct 2014 05:53:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 21 Oct 2014 05:53:17 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9L5rB97030635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 21 Oct 2014 01:53:11 -0400 Received: from host2.jankratochvil.net (ovpn-116-79.ams2.redhat.com [10.36.116.79]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9L5r6fC006646 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Tue, 21 Oct 2014 01:53:09 -0400 Date: Tue, 21 Oct 2014 05:53:00 -0000 From: Jan Kratochvil To: Pete Delaney Cc: Andreas Arnez , "Discussion list for crash utility usage, maintenance and development" , GDB Development Subject: Re: gdb on KDUMP files Message-ID: <20141021055306.GA32003@host2.jankratochvil.net> References: <20141002102700.3eba84a5@suse.cz> <87d29rhrce.fsf@br87z6lw.de.ibm.com> <20141017115550.GA7123@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00083.txt.bz2 On Tue, 21 Oct 2014 06:27:32 +0200, Pete Delaney wrote: > > Nowadays it is only enough to use during configure: > > --enable-64-bit-bfd > > I'll give it a try. I provided O_LARGEFILE to the gdb configure AC_SYS_LARGEFILE is there since 2009: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=da2f07f1aa5f8bdeb957df2c520f1d46e6f21bd5 > but I didn't know about this option. With everything going 64-bit these > days, why isn't it the default. I'm running gdb on a 64 bit machine and > having trouble reading 64 bit core files. Seems like this should work > correctly without any additional configure options. It does. --enable-64-bit-bfd is useful only for 32-bit machines which for some reason need to deal with 64-bit files. If there is some problem on 64-bit host it is some other issue than --enable-64-bit-bfd. > About 8 years ago I could read a 32 bit KDUMP with gdb > and, as I recall, each CPU looked like a thread; just like kgdb > displayed CPU's as threads. I also think embedded JTAG setups > should do the same. > > Are you implying that with: > > --enable-64-bit-bfd > > I should be able to do that now on a 64-bit machine looking On 64-bit machine --enable-64-bit-bfd has no effect. > At 64 bit core dumps and see the back trace for the current > CPU's at the time of the KDUMP? I do not deal with kdump files to answer that. > I found the Documentation/kdump/gdbmacros.txt out of date > And had to fix them to work. :( This file is not maintained by this (GDB) project. Jan