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
