mips: elfinfo

[Maxim Uvarov]

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.

> 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)
>



-- 
Best regards,
Maxim Uvarov