[PATCH] Parse 64 bit VMCOREINFO on 32 bit userland

[Bernhard Walle]

Hi Ken'ichi,

* Ken'ichi Ohmichi [2008-11-28 10:16]:
> Bernhard Walle wrote:
> > This bug fixes the problem that on a 32 bit userland makedumpfile (as common
> > on the PPC platform) the parsing of the 64 bit VMCOREINFO fails with:
> > 
> >    # makedumpfile -c /home/sachin/dump/vmcore vmcore.filtered
> >    read_vmcoreinfo_symbol: Invalid data in /tmp/vmcoreinfowVoyJK:
> >    SYMBOL(mem_section)=c000000000bb4400
> > 
> > We just need to assume that the symbols are always 'unsigned long long' (64 bit)
> > instead of 'unsigned long' (native pointer size on Linux platforms).
> 
> I agree with this patch basically. But I have not tested kdump on PPC64
> platform (PPC32 also) and I don't know it well. So may I ask a question ?
> 
> For PPC64 kdump, is it common thing that makedumpfile runs on PPC32 ?
> In other words, do you use PPC32 kernel as 2nd-kernel for PPC64 kdump ?

No. Both kernels are 64 bit. The system does not boot with a 32 bit
kernel (it's not like x86-64 where the system is entirely i386
compatible from the beginning).

But for openSUSE and SLES 9/SLES 10 at least -- that are the only
distributions I know on PPC [1] --, the userland is 90 % ppc32 and only
some small stuff is ppc64 (like an additional 64 bit C library and stuff
that is absolutely needed to be 64 bit like crash since that's not yet
capable of debugging 64 bit dumps on 32 bit).

Having that said, every tool that not needs to be 64 bit is a plus. 
Some month ago I already sent patches to 'fix' makedumpfile for 64 bit
kernels and you accepted them.


Regards,
Bernhard


[1] I'm not in the PPC team, so I don't know that platform very well,
    either. And I personally don't like that approach (64 bit kernel,
    32 bit userland) very much because it does cause trouble, but I
    cannot make decisions. ;-)
-- 
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development