From: John Reiser <jreiser@BitWagon.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: vamsi krishna <vamsi.krishnak@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: Idea to create a elf executable from running program [process2executable]
Date: Sun, 19 Mar 2006 11:41:12 -0800 [thread overview]
Message-ID: <441DB3D8.4050807@BitWagon.com> (raw)
In-Reply-To: <1142760646.3018.8.camel@laptopd505.fenrus.org>
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.
--
next prev parent reply other threads:[~2006-03-19 19:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-18 22:22 Idea to create a elf executable from running program [process2executable] vamsi krishna
2006-03-19 9:30 ` Arjan van de Ven
2006-03-19 19:41 ` John Reiser [this message]
2006-03-20 8:33 ` Cedric Le Goater
2006-03-20 8:41 ` vamsi krishna
2006-03-21 8:43 ` Roberto Nibali
2006-03-22 5:18 ` Andrew Shewmaker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=441DB3D8.4050807@BitWagon.com \
--to=jreiser@bitwagon.com \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vamsi.krishnak@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox