mips: elfinfo

[Simon Horman]

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)