I'm glad to see this discussion today.... > 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 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. 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 At 64 bit core dumps and see the back trace for the current CPU's at the time of the KDUMP? I found the Documentation/kdump/gdbmacros.txt out of date And had to fix them to work. :( -piet On Fri, 17 Oct 2014 13:24:01 +0200, Andreas Arnez wrote: > > 4. Ability to use 64-bit files on 32-bit platforms (to handle PAE) This was: https://bugzilla.redhat.com/show_bug.cgi?id=457187 Nowadays it is only enough to use during configure: --enable-64-bit-bfd Additionally Fedora is carrying for Linux kernel support: http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-6.5-bz203661-emit-relocs.patch dsicussed in the thread: https://sourceware.org/ml/gdb/2006-08/msg00137.html Jan -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
