Messages in this thread | | | Date | Mon, 20 Mar 2006 09:33:10 +0100 | From | Cedric Le Goater <> | Subject | Re: Idea to create a elf executable from running program [process2executable] |
| |
vamsi krishna wrote: > Hello All, > > I have been working on an idea of creating an executable from a > running process image. > > MOTIVATION: > Process migration among the nodes in distributed computing, > checkpointing process state. > > BASIS: > > The basis of my idea would be update the existing executable with > extra PHDRS (Program Headers) with type PT_LOAD and each of these > headers corresponding the vaddr mapping from /proc/<pid>/maps. > > I have done some basic study of kernels loders code in > 'fs/binfmt_elf.c' especially code in 'load_elf_binary' function, the > following is my understanding. > <------------------------------------------> > bss=0; > brk=0; > foreach (phdr in elf_header){ > > if(phdr->type == PT_LOAD){ > if( phdr->filesize < phdr->memsize){ > /* Segment with .bss, so update brk and bss*/ > } > else { > /* Just map it*/ > } > } > /*Update brk bss*/ > } > <------------------------------------> > > from the above the kernel is updating brk, thus creating the start of > sbrk(0) only when it sees a PT_LOAD segment with filesize<memsize. So > if I create a elf executable with all PT_LOAD segments with out any > segments with filesize < memsize. The kernel will set brk base i.e > sbrk(0) to the value phdr->vaddr+phdr->memsize of the last PT_LOAD > segment its mapping? so do I need to reoder my PT_LOAD segments so > that the heap goes as the last PT_LOAD segment?
Why don't you let execve() finish its job before modifying the mapping ?
Once execve returns, the segments are mapped and you are free to remap them however you want and fill them in with a state previously saved on disk.
C. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |