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-rel...
dsicussed in the thread:
https://sourceware.org/ml/gdb/2006-08/msg00137.html
Jan