* 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
* 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).