On Thu, Dec 16, 2010 at 06:33:25PM +0300, Maxim Uvarov wrote:
> 2010/12/16 Simon Horman <horms at verge.net.au>:
> > Hi Maxim,
> >
> > I noticed that your change "Patch adds kernel data section to final vmcore.
> > This forces gdb read kernel" causes the build to break as it was applied
> > after Eric's "crashdump: Move kern_vaddr_start from kexec_info into
> > crash_elf_info" patch.
> >
> > I have it in mind to resolve this something along the lines of
> > the patch below. However, I now see the following warning:
> >
> > ? ? ? ?kexec/arch/mips/crashdump-mips.c: In function `get_kernel_vaddr_and_size':
> > ? ? ? ?kexec/arch/mips/crashdump-mips.c:81: warning: integer constant is too large for "unsigned long" type
> >
> > Which corresponds to this code:
> >
> > ? ? ? ?elf_info->kern_vaddr_start = elf_info->kern_paddr_start |
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0xffffffff80000000UL;
> >
> > I am compiling for 32-bit, so at a glance that constant does
> > seem to large.
> >
>
> Ah, yes this values does not fit to 32 bit UL.
>
> > Also, if you have any tips on a cross-compiling environment for 64bit
> > on a x86_32 or x86_64 host I would be most grateful.
> >
>
> I tested it with building on 32 bit host. readelf -a shows that vmcore
> had memory segment according to kernel memory.
> So that, gdb began to read real values instead of uninitialized.
>
> Actually elf_info->kern_paddr_start | 0xffffffff80000000UL; is needed
> only for 64 bit mips.
> Because we read kernel memory ranges from /proc/vmcore and there are
> values without 0xffffffff at the beginning.
> But 0xfffff... are needed in case if we need access to this address from kernel.
>
> 32 bit mips kernel does not need adding 0xfffffff. But it think there
> will be only warning and nothing wrong.
Understood, but it would be nice to eliminate the warning.
As load_crashdump_segments() is already 32/64 bit aware I wonder
if we could just pass appropriate constant from there as
a parameter of get_kernel_vaddr_and_size().
Perhaps something like the following which
applies on top of my previous patch.
diff --git a/kexec/arch/mips/crashdump-mips.c b/kexec/arch/mips/crashdump-mips.c
index b937ab5..aa50109 100644
--- a/kexec/arch/mips/crashdump-mips.c
+++ b/kexec/arch/mips/crashdump-mips.c
@@ -70,7 +70,8 @@ static int get_kernel_paddr(struct crash_elf_info *elf_info)
return -1;
}
-static int get_kernel_vaddr_and_size(struct crash_elf_info *elf_info)
+static int get_kernel_vaddr_and_size(struct crash_elf_info *elf_info,
+ unsigned long start_offset)
{
uint64_t end;
@@ -78,7 +79,7 @@ static int get_kernel_vaddr_and_size(struct crash_elf_info *elf_info)
return -1;
elf_info->kern_vaddr_start = elf_info->kern_paddr_start |
- 0xffffffff80000000UL;
+ start_offset;
if (parse_iomem_single("Kernel data\n", NULL, &end) == 0) {
elf_info->kern_size = end - elf_info->kern_paddr_start;
#ifdef DEBUG
@@ -358,18 +359,20 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
struct memory_range *mem_range;
crash_create_elf_headers_func crash_create = crash_create_elf32_headers;
struct crash_elf_info *elf_info = &elf_info32;
+ unsigned long start_offset = 0x80000000UL;
#ifdef __mips64
if (arch_options.core_header_type == CORE_TYPE_ELF64) {
elf_info = &elf_info64;
crash_create = crash_create_elf64;
+ start_offset = 0xffffffff80000000UL;
}
#endif
if (get_kernel_paddr(elf_info))
return -1;
- if (get_kernel_vaddr_and_size(elf_info))
+ if (get_kernel_vaddr_and_size(elf_info, start_offset))
return -1;
if (get_crash_memory_ranges(&mem_range, &nr_ranges) < 0)
