On 11/17/06, Vivek Goyal <[EMAIL PROTECTED]> wrote: > 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.
Oh, but if we ever want to support relocatable kernels on i386 then we would need a separate one there too, right? Thanks! / magnus _______________________________________________ fastboot mailing list fastboot@lists.osdl.org https://lists.osdl.org/mailman/listinfo/fastboot
