* Re: gdb on KDUMP files [not found] ` <20141002102700.3eba84a5@suse.cz> @ 2014-10-17 11:24 ` Andreas Arnez 2014-10-17 11:55 ` Jan Kratochvil 0 siblings, 1 reply; 6+ messages in thread From: Andreas Arnez @ 2014-10-17 11:24 UTC (permalink / raw) To: Discussion list for crash utility usage, maintenance and development Cc: GDB Development Petr, I'm copying the GDB mailing list, because this is probably of interest to the GDB community as well. On Thu, Oct 02 2014, Petr Tesarik wrote: > On Thu, 2 Oct 2014 03:18:55 +0000 > Pete Delaney <pdelaney@silver-peak.com> wrote: > >> Hi: >> >> Six years ago Dave and I were discussing using gdb on KDUMP files: >>[...] >> >> 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)? > Last time I looked (approx. 1.5 years ago) the main missing pieces were: > > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gdb on KDUMP files 2014-10-17 11:24 ` gdb on KDUMP files Andreas Arnez @ 2014-10-17 11:55 ` Jan Kratochvil [not found] ` <ffc61e9ab6e7423eb7919f0e0828266d@BY2PR04MB173.namprd04.prod.outlook.com> 2014-10-22 0:54 ` Pete Delaney 0 siblings, 2 replies; 6+ messages in thread From: Jan Kratochvil @ 2014-10-17 11:55 UTC (permalink / raw) To: Andreas Arnez Cc: Discussion list for crash utility usage, maintenance and development, GDB Development 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <ffc61e9ab6e7423eb7919f0e0828266d@BY2PR04MB173.namprd04.prod.outlook.com>]
* Re: gdb on KDUMP files [not found] ` <ffc61e9ab6e7423eb7919f0e0828266d@BY2PR04MB173.namprd04.prod.outlook.com> @ 2014-10-21 5:53 ` Jan Kratochvil 0 siblings, 0 replies; 6+ messages in thread From: Jan Kratochvil @ 2014-10-21 5:53 UTC (permalink / raw) To: Pete Delaney Cc: Andreas Arnez, Discussion list for crash utility usage, maintenance and development, GDB Development 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: gdb on KDUMP files 2014-10-17 11:55 ` Jan Kratochvil [not found] ` <ffc61e9ab6e7423eb7919f0e0828266d@BY2PR04MB173.namprd04.prod.outlook.com> @ 2014-10-22 0:54 ` Pete Delaney 2014-10-24 0:34 ` Doug Evans 1 sibling, 1 reply; 6+ messages in thread From: Pete Delaney @ 2014-10-22 0:54 UTC (permalink / raw) To: Jan Kratochvil, Andreas Arnez Cc: Discussion list for crash utility usage, maintenance and development, GDB Development, Pete Delaney, Piet Delaney > Nowadays it is only enough to use during configure: > --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: piet.delaney@gmail.com -----Original Message----- From: gdb-owner@sourceware.org [mailto:gdb-owner@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 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gdb on KDUMP files 2014-10-22 0:54 ` Pete Delaney @ 2014-10-24 0:34 ` Doug Evans 2014-10-30 10:14 ` Pedro Alves 0 siblings, 1 reply; 6+ messages in thread From: Doug Evans @ 2014-10-24 0:34 UTC (permalink / raw) To: Pete Delaney Cc: Jan Kratochvil, Andreas Arnez, Discussion list for crash utility usage, maintenance and development, GDB Development, Piet Delaney On Tue, Oct 21, 2014 at 5:53 PM, Pete Delaney <pdelaney@silver-peak.com> wrote: >> Nowadays it is only enough to use during configure: >> --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. Hi. It's not clear from the description that this is a largefile problem. As an experiment, what happens if you build with CFLAGS="-g -O2 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE" ? [not all of these macros may be necessary, configure should be defining _FILE_OFFSETS_BITS=64, THIS IS JUST AN EXPERIMENT] > > -----Original Message----- > From: gdb-owner@sourceware.org [mailto:gdb-owner@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 > > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gdb on KDUMP files 2014-10-24 0:34 ` Doug Evans @ 2014-10-30 10:14 ` Pedro Alves 0 siblings, 0 replies; 6+ messages in thread From: Pedro Alves @ 2014-10-30 10:14 UTC (permalink / raw) To: Doug Evans, Pete Delaney Cc: Jan Kratochvil, Andreas Arnez, Discussion list for crash utility usage, maintenance and development, GDB Development, Piet Delaney On 10/24/2014 01:34 AM, Doug Evans wrote: > On Tue, Oct 21, 2014 at 5:53 PM, Pete Delaney <pdelaney@silver-peak.com> wrote: >>> Nowadays it is only enough to use during configure: >>> --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. > > Hi. > > It's not clear from the description that this is a largefile problem. It sounds likely to be related to points #1 and #2 described earlier in the discussion: On 10/17/2014 12:24 PM, Andreas Arnez wrote: >> > Last time I looked (approx. 1.5 years ago) the main missing pieces were: >> > >> > 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. Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-10-30 10:14 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <b3a5a177772a47e8bf740e3422befa6a@BY2PR04MB173.namprd04.prod.outlook.com>
[not found] ` <20141002102700.3eba84a5@suse.cz>
2014-10-17 11:24 ` gdb on KDUMP files Andreas Arnez
2014-10-17 11:55 ` Jan Kratochvil
[not found] ` <ffc61e9ab6e7423eb7919f0e0828266d@BY2PR04MB173.namprd04.prod.outlook.com>
2014-10-21 5:53 ` Jan Kratochvil
2014-10-22 0:54 ` Pete Delaney
2014-10-24 0:34 ` Doug Evans
2014-10-30 10:14 ` Pedro Alves
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).