This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: gdb on KDUMP files
- From: Pedro Alves <palves at redhat dot com>
- To: Doug Evans <dje at google dot com>, Pete Delaney <pdelaney at silver-peak dot com>
- Cc: Jan Kratochvil <jan dot kratochvil at redhat dot com>, Andreas Arnez <arnez at linux dot vnet dot ibm dot com>, "Discussion list for crash utility usage, maintenance and development" <crash-utility at redhat dot com>, GDB Development <gdb at sourceware dot org>, Piet Delaney <piet dot delaney at gmail dot com>
- Date: Thu, 30 Oct 2014 10:14:37 +0000
- Subject: Re: gdb on KDUMP files
- Authentication-results: sourceware.org; auth=none
- References: <b3a5a177772a47e8bf740e3422befa6a at BY2PR04MB173 dot namprd04 dot prod dot outlook dot com> <20141002102700 dot 3eba84a5 at suse dot cz> <87d29rhrce dot fsf at br87z6lw dot de dot ibm dot com> <20141017115550 dot GA7123 at host2 dot jankratochvil dot net> <edf4b8070b6c431e832841ebfb03ea84 at BY2PR04MB173 dot namprd04 dot prod dot outlook dot com> <CADPb22T9XZoDaDXBSuCr3BtbKAi84VYTZVDvfsqs-sdZDCVpag at mail dot gmail dot com>
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