[lkml]   [2006]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Idea to create a elf executable from running program [process2executable]
Arjan van de Ven wrote:
> Have you looked at the emacs dumper? This is more or less describing how
> emacs makes it's executable during the build process ;)
> (and yes it's horrid ;)

The emacs dumper does not address the fundamental problem with the kernel,
which Vamsi Krishna identified:
> Is there any way we can tell the elf loader to force the vaddr for
> sbrk(0) i.e brk base ?

load_elf_binary()/binfmt_elf.c sets the brk base from the PT_LOAD with
highest virtual address range. A re-executed dump (or newly decompressed
executable that was stored compressed in the file system, etc.) may well
want to set the brk base below some of its "initial" PT_LOAD [initial as
far as execve() is concerned], but the kernel provides no means to cooperate.
Emacs does not care because it colludes on both ends (the state save and
the restore), but the user does not want to require that the general
restored process must know these details of history.

It seems to me that a proper solution requires a new .p_type PT_BRK
which (if present) would cause the kernel to set the brk base
from the corresponding .p_vaddr, independent of the address ranges
specified in any PT_LOAD. Or, eliminate the whole concept of brk, which
is an anachronism from the days of primitive address-space management.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-03-19 20:44    [W:0.072 / U:15.812 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site