Magnus Damm wrote: > Hi Dave, > > On 11/16/06, Dave Anderson <[EMAIL PROTECTED]> wrote: > > > > Vivek Goyal <[EMAIL PROTECTED]> wrote: > > - I think this patch will break compatibility with gdb as we are not > > mapping > > kernel in virtual address space. All the physical chunks are being mapped > > to linearly mapped region in virtual address space and none is being > > mapped > > to kernel text virtual address region. > > > > Vivek, > > > > Wouldn't it also break the algorithm used by the crash utility > > to determine the kernel's physical base address? > > > > Recall that we decided to search for the PT_LOAD segment > > starting at __START_KERNEL_map, and then calculate the > > physical base address like so: > > > > phys_base = phdr->p_paddr - (phdr->p_vaddr & ~(__START_KERNEL_map)); > > But older versions the kexec-tools doesn't add the kernel PT_LOAD > segment on x86_64, and on i386 that does not happen at all. Does that > mean that crash needs a new version of kexec-tools to work properly? > Maybe I'm misunderstanding... >
The calculation above is only for relocatable x86_64 kernels; what I failed to mention is that it only takes affect if the "phys_base" entry point exists, which only exists in relocatable x86_64 kernels. In all other x86_64 kernels, the default physical address base value of zero is used. The p_vaddr field of the PT_LOAD segments is only used by the crash utility in two circumstances: 1. to determine the physical base address for relocatable x86_64 kdump vmcores, and 2. to determine the physical base address for all ia64 kdump vmcores, which have a singular region 5 PT_LOAD segment mapping the kernel's text/static data (in addition to region 7 segments for the rest of physical memory). Dave >
_______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
