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