Re: gdb on KDUMP files

Pete Delaney <[email protected]>
Newsgroups gmane.linux.kernel.crash-dump.crash-utility,gmane.comp.gdb.devel
Message-ID <ffc61e9ab6e7423eb7919f0e0828266d@BY2PR04MB173.namprd04.prod.outlook.com>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.