[Crash-utility] [PATCH] crash: ARM: support LPAE

[Dave Anderson]

----- Original Message -----

> > 
> > I believe the 32-bit vs. 64-bit ELF header is configurable, correct?
> 
> Now if max phyiscal address of ARM platform execceding 4G, kexec
> creates 64-bit ELF header. Otherwise, it creates 32-bit ELF header.
> 
> > On RHEL, by default we configure 64-bit ELF headers for 32-bit x86
> > machines regardless of their memory size.  So you should be able to
> > create a vmcore with a 64-bit ELF header on a system that has less
> > than 4GB of physical memory.
> 
> For now the ARM kernel can not parse 64-bit ELF header without my patch
> locating at "https://lkml.org/lkml/2014/5/3/63". So perhaps we can not
> create a vmcore with 64-bit ELF header for ARM. Otherwise all old
> ARM kernels can not generate vmcores correctly.

OK.
 
> > But as I mentioned above, there will need to be at least one fix for
> > the crash utility, because it will fail at line 258 of netdump.c.
> > To accept 64-bit ARM headers, there would need to be a additional
> > case statement like this:
> > 
> >                  case EM_ARM:
> >                         if (machine_type_mismatch(file, "ARM", NULL,
> >                             source_query))
> >                                 goto bailout;
> >                         break;
> > 
> > I'm not sure whether any other fixes would be required?
> 
> On our platform, I usually use makedumpfile to reduce vmcore.
> Then it comes to diskdump format.
> 
> But when I dealed with original vmcores. This error occurs:
> 
> .....
> WARNING: machine type mismatch:
>          crash utility: ARM
>          ../github/1381_4/vmcore: (unknown)
> 
> crash: ../github/1381_4/vmcore: not a supported file format
> 
> When fully checking is done, I will send the related patches.
> Sorry for this mistake!

OK thanks -- no problem...

> > Note that in some earlier kernels, the "_text" symbol is often much
> > higher.  But I presume that it would be highly unlikely that the difference
> > would ever be 0x5000 in an older kernel -- so until somebody reports a
> > problem, it seems OK to do it that way.
> > 
> > However, just in case the layout changes in the future, there should be
> > a fail-safe check for the VMCOREINFO_CONFIG(ARM_LPAE) in arm_init(),
> > that does something like this:
> > 
> >     if ((string = pc->read_vmcoreinfo("CONFIG_ARM_LPAE"))) {
> >             machdep->flags |= PAE;
> >             free(string);
> >     } else
> >             [check for 0x5000 difference]
> > 
> > There's really no need to check for the "y" contents of the string, because
> > if the entry exists, then CONFIG_ARM_LPAE is configured.
> 
> Yes, you advice is much better. We should add this. And perhaps we should also find
> another way to recognise LPAE enableed vmcores for old kernels, rather than pg_dir_size.

The only other way I can think of is if there is a kernel symbol that only exists
in LPAE kernels.  I took a quick look at the kernel sources, and didn't see anything
obvious, but something may exist.

But the swapper_pg_dir size check is a reasonable way to do it.  Perhaps a slightly
better way would be to compare the symbol value of "swapper_pg_dir" with next higher
symbol.  Something like this:

  sp1 = symbol_value("swapper_pg_dir");
  sp2 = next_symbol_value("swapper_pg_dir", NULL);
  difference = sp2->value - sp2->value;

In my sample set of ARM dumpfiles, the above results in 0x4000 on all of the non-LPAE
kernels.

> 
> BTW, what do you think about parseing big endian vmcores(such as ARMEB vmcores) on
> x86-64 host?

That cannot be done.  The 32-bit x86 binary built on an x86_64 host will be 
little-endian.  The "target=xxx" capability only works if the host machine
endianness and data type sizes are the same as the target architecture.

Dave