[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Crash-utility] gdb on KDUMP files



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]