Discussion:
gdb on KDUMP files
(too old to reply)
Andreas Arnez
2014-10-17 11:24:01 UTC
Permalink
Petr,

I'm copying the GDB mailing list, because this is probably of interest
to the GDB community as well.
On Thu, 2 Oct 2014 03:18:55 +0000
[...]
Anyone know what's going on?
[...]
I'm glad you're interested in using GDB to read kernel dump files,
especially if you're willing to make it work for real. I have proposed
more than once that the crash utility be re-implemented in pure gdb.
Incidentally, I've tossed this idea around as well. Do you have a
pointer to one of these proposals (and discussions, if any)?
1. Use of physical addresses (described above)
I guess this includes the capability to translate virtual to physical
addresses, using the kernel's page tables?
2. Support for multiple virtual address spaces (for different process
contexts)
One way of dealing with this might be to represent the different virtual
address spaces as multiple inferiors.
3. Ability to read compressed kdump files
4. Ability to use 64-bit files on 32-bit platforms (to handle PAE)
In addition, there might be:

5. Support kernel modules and represent them as "shared objects".

6. Understand the kernel's task structures. Represent multiple tasks
within the same "inferior" as threads in GDB.

7. Format functions: Extract information from kernel data structures
and show it in a digested, more readable, form. Perhaps such
functions can be implemented as Python scripts.

Among others, I'd envision the following GDB commands:

file <vmlinux> Specify vmlinux Elf image
target kdump <kdump-file> Load kdump
info sharedlibrary List kernel modules
info inferiors List address spaces ("processes")
inferior <id> Switch to certain address space
info threads List threads in current address space
bt, up, down, frame <id> Usual behavior
generate-core-file Write core dump for the current inferior
linux cmdline Show kernel command line
linux kmesg Show kernel message buffer
linux cpuinfo List CPUs and their state
linux ... Other format functions

All of this together may not be a small task, and there are still
various open questions, e.g. how to deal with interrupt contexts. But I
think we could already provide useful functionality with a smaller
initial development stage and defer features like multiple address space
support, PAE support, format functions, etc., to a later stage.

--
Andreas
Jan Kratochvil
2014-10-17 11:55:50 UTC
Permalink
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
Pete Delaney
2014-10-21 04:27:32 UTC
Permalink
I'm glad to see this discussion today....
Post by Jan Kratochvil
--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
Post by Jan Kratochvil
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
Jan Kratochvil
2014-10-21 05:53:06 UTC
Permalink
Post by Pete Delaney
Post by Jan Kratochvil
--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
Post by Pete Delaney
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.
Post by Pete Delaney
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.
--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.
Post by Pete Delaney
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.
Post by Pete Delaney
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
Pete Delaney
2014-10-22 00:53:55 UTC
Permalink
Post by Jan Kratochvil
--enable-64-bit-bfd
I tried
configure --enable-64-bit-bfd --enable-largefile

And gdb still has problems accessing memory in the KDUMP that the crash-utility can read.
For example crash can walk the task list but when the gdb macro tries
To access the memory of the second task gdb says it can't access memory.

-piet



--
Pete/Piet Delaney
O: +1 408 935-1813
C: +1 408 646-8557
H: +1 408 243-8872
Home Email: ***@gmail.com




-----Original Message-----
From: gdb-***@sourceware.org [mailto:gdb-***@sourceware.org] On Behalf Of Jan Kratochvil
Sent: Friday, October 17, 2014 4:56 AM
To: Andreas Arnez
Cc: Discussion list for crash utility usage, maintenance and development; GDB Development
Subject: Re: gdb on KDUMP files
Post by Jan Kratochvil
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

Loading...