On Thu, Nov 16, 2006 at 12:17:08PM +0900, 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... >
Older version of kexec-tools was not creating a PT_LOAD separately but it was mapping first 40MB in kernel text range (ffffffff80000000 - ffffffff82800000 (=40MB) kernel text mapping, from phys 0) and rest of the memory in linearly mapped region. (ffff810000000000 - ffffc0ffffffffff (=46bits) direct mapping of all phys. memory). Though its not the best way to handle and we ought to create a separate PT_LOAD header for kernel. So that same physical memory will be mapped twice with two PT_LOAD headers (as their virtual addresses are different). Case of i386 is simple, kernel and linearly mapped regions are not differnt. So you can avoid creating a separate PT_LOAD for kernel. Thanks Vivek _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
