On Tue, Dec 21, 2010 at 10:04:34AM +0300, Maxim Uvarov wrote: > 2010/12/20 Simon Horman <horms at verge.net.au>: > > 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. > > > Yes, that has to work. Thanks. Thanks, I have pushed this and the previous change.
