FYI: x86_64 bug when using gdb with vmcore

Simon Horman horms at verge.net.au
Wed Feb 17 19:40:00 EST 2010


On Wed, Feb 17, 2010 at 08:49:46AM -0500, Dave Anderson wrote:
> 
> ----- "Simon Horman" <horms at verge.net.au> wrote:
> 
> > On Fri, Feb 05, 2010 at 11:53:18AM -0500, Dave Anderson wrote:
> > > 
> > > The kexec/arch/x86_64/crashdump-x86_64.h file contains a
> > > stale PAGE_OFFSET value.  In 2.6.27 it was changed from
> > > 0xffff810000000000UL to 0xffff880000000000UL.  This is
> > > only a problem when using gdb with the vmlinux/vmcore
> > > pair, because gdb relies upon the PT_LOAD segment's p_vaddr
> > > values in the ELF header to be correct.
> > > 
> > > Anyway, in the RHEL6 kexec-tools, this simple patch 
> > > was made:
> > > 
> > > -#define PAGE_OFFSET            0xffff810000000000UL
> > > +#define PAGE_OFFSET            0xffff880000000000UL
> > > 
> > > which is OK since the RHEL6 version of kexec-tools
> > > will only be used with RHEL6 kernels.  
> > > 
> > > But for backwards compatibility, the better way to do 
> > > it would be to check the utsname of the running kernel, 
> > > and use the right value.
> > > 
> > > But again, this is only required for gdb usage.  The 
> > > crash utility (and makedumpfile) make kernel version checks 
> > > to determine which x86_64 PAGE_OFFSET value is applicable,
> > > and don't rely on the ELF header p_vaddr values for
> > > the unity-mapped regions.  
> > 
> > Hi Dave,
> > 
> > Something like this?
> 
> Looks good to me -- all except for the second "if" statement/typo below:  

Thanks, 2.4.27 was a special time for me :-)

I've fixed that up and pushed the commit.

> > +int arch_init(void)
> > +{
> > +	int kv;
> > +
> > +	kv = kernel_version();
> > +	if (kv < 0)
> > +		return -1;
> > +
> > +	if (kv < KERNEL_VERSION(2, 4, 27))
> > +		page_offset = PAGE_OFFSET_PRE_2_6_27;
> > +	else
> > +		page_offset = PAGE_OFFSET;
> > +
> > +	return 0;
> > +}
> 
> Thanks,
>   Dave



More information about the kexec mailing list