On Wed, May 25, 2016 at 11:47:33AM +0530, Pratyush Anand wrote:
> On Tue, May 3, 2016 at 3:51 PM, Russell King <rmk at arm.linux.org.uk> wrote:
> > diff --git a/kdump/kdump.c b/kdump/kdump.c
> > index 1f5b984..34d2149 100644
> > --- a/kdump/kdump.c
> > +++ b/kdump/kdump.c
> > @@ -284,7 +284,8 @@ int main(int argc, char **argv)
> > }
> >
> > /* Get the program header */
> > - phdr = map_addr(fd, sizeof(*phdr)*(ehdr->e_phnum), ehdr->e_phoff);
> > + phdr = map_addr(fd, sizeof(*phdr)*(ehdr->e_phnum),
> > + start_addr + ehdr->e_phoff);
>
> This is fine. But at the same time should n't we also fix the offset
> for mmap of memory segments? For memory segments, offset is
> phdr[i].p_offset, and I do not see generate_new_headers() taking care
> of start_addr.
Unfortunately not. The reason is, p_offset is not an offset, but an
absolute address - see kexec/crashdump-elf.c, which is the bit of
code which creates the table and writes it into kernel memory when
loading the panic kernel:
phdr->p_offset = phdr->p_paddr = notes_addr;
phdr->p_offset = phdr->p_paddr = vmcoreinfo_addr;
phdr->p_offset = phdr->p_paddr = elf_info->kern_paddr_start;
mstart = range->start;
phdr->p_offset = mstart;
phdr->p_paddr = mstart;
etc. So, p_offset is also the physical address, not the file offset.
Of course, that could be a bug in crashdump-elf.c. To change that,
we would also need to fix crashdump-elf.c in lock-step as well.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
