mips: elfinfo

[Simon Horman]

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.