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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
