From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Removal of unexec support from glibc malloc Date: Mon, 18 Jan 2016 12:05:36 -0800 Message-ID: <569D4590.4030203@dancol.org> References: <569CDB81.6040600@redhat.com> <569D3BE0.6050103@cs.ucla.edu> <569D4207.4060209@cs.ucla.edu> <83mvs2d5b2.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bM0CX4Vdg7uhh6lPXF0CT9wGinpMwhPMc" X-Trace: ger.gmane.org 1453147560 24068 80.91.229.3 (18 Jan 2016 20:06:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Jan 2016 20:06:00 +0000 (UTC) Cc: fweimer@redhat.com, Emacs-devel@gnu.org To: Eli Zaretskii , Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 18 21:05:59 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aLG3r-0004fO-Dp for ged-emacs-devel@m.gmane.org; Mon, 18 Jan 2016 21:05:59 +0100 Original-Received: from localhost ([::1]:33444 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLG3q-0003Cb-GM for ged-emacs-devel@m.gmane.org; Mon, 18 Jan 2016 15:05:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41713) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLG3c-0003CJ-O8 for Emacs-devel@gnu.org; Mon, 18 Jan 2016 15:05:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLG3b-0006bs-VC for Emacs-devel@gnu.org; Mon, 18 Jan 2016 15:05:44 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:49046) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLG3b-0006bm-Ny; Mon, 18 Jan 2016 15:05:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=8TSMqtW7HGDIQCnMQ54sVzFvaPPAZmQmFS/47ffqvgE=; b=NKKd6Ndc1KCEQiYmyei9jSZcL1gMeshyBCrSmI40L56Q9nVLDt7yLhcgxGnUl8nPutg+WE3yqmiL9YBXtxNBWDx72+yew4xvxBtrNWPVid4Kc0iAdQzAExXsNng0GqpHJETY2RPw02n1RwnQpDehX9W3/00mz0xvmGPygwEBQPGrD2tRiDtmOFz10ZPKrjpsMCyyL3xmy0I4kjoDKOIIHyW2RirOyNm8g0bwXU7Q2ySdKSTp459mvuHcN5fSGIGwafsJRuEi2+q+C0P51rm5hhodC8W84bBi+KeGUX1U2ZiorKgb4D/jdqDVvFUcOp6X60Z2PbWhe/02LgAUusOcPQ==; Original-Received: from [2620:10d:c090:180::1:8d3f] (helo=[IPv6:2620:10d:c081:1103:2ab2:bdff:fe1c:db58]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1aLG3b-0002fV-4u; Mon, 18 Jan 2016 12:05:43 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <83mvs2d5b2.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:198283 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bM0CX4Vdg7uhh6lPXF0CT9wGinpMwhPMc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/18/2016 12:02 PM, Eli Zaretskii wrote: >> From: Paul Eggert >> Date: Mon, 18 Jan 2016 11:50:31 -0800 >> >> Emacs could live without the current unexec in a semi-portable way by = doing what=20 >> XEmacs does, which is to write out data and mmap it in later (sorry, d= on't know=20 >> the details). There are other possibilities, e.g., have unexec write o= ut the=20 >> state in the form of C files that are compiled and linked in the usual= way to=20 >> build a faster-starting executable (this would be an Emacs API change,= though).=20 >> Any such changes would take some time to hack into something reliable = and=20 >> portable, and so will have to wait until after Emacs 25 is out. >=20 > There's also what the MS-Windows port does (temacs allocates off a > static array), which AFAIK is entirely portable, and doesn't require > mmap. See w32heap.c. >=20 It's a portable stopgap, maybe, but a real portable dumper would be _much_ better, since then Emacs could be a much safer position-independnent executable (as a portable dumper would relocate the dump as it loads, since it knows where all the pointers are). --bM0CX4Vdg7uhh6lPXF0CT9wGinpMwhPMc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWnUWQAAoJEN4WImmbpWBlAi0QAITW0fqHqGu9DyHTqNCsMSQk hhJI2IOlZjiV6XoLqmOZfSeJTv/4pMBRTLh/VoBbcy8Iy1jEpca0IG44z6k5xUqk tMtEXFC1sKFsgtS6PhUlshGjXRD/bTZAQQ9B4epXe1tN5aRMnIC+exYAVCectgh5 bXxB2VT4QU81inVSYEbryTM9qMcAwVUC2pdVjDL3pi/rrWxl4PdPultIGfBxpGiN HGoGE2FxTmXJkVuqjU+tznhBFHt+cg1vHDoHMSNj5X8C8/4P75texk1n2O1Ch5/V x987QBaDXbaIwHRzDjO0HIed+WnYqXis26EbkiOJ+bhtJgpuaL10S4/g/TdVO+d4 e4m/yInmiJPV/UPAinBq/SSChOYkn6dEd4BD988UfgiTb8uCOf7+mJgm5xqQoJGw 79ZImuD7UNuEMLdZB+nFqpmDAkADW267CkP8PRo4sj2uWSMzGx1zBoJrWlIgrQqr vOPdv0A8MH/sgRlCgoLpIKx7HXbuoIYLvxnTfpKBN3waSjcvfWZ0pKFFTmFlFZpu hbm8+TfXckKZU4YGmBEJ0rPpIkDjSkV6jbGkbS/7nvN/fGLkB49XnJo1ziftLfob 3c/srpWwyMO+CYPd57KGw0ZtyTctXH5Y0NW5n1ZQgVBPsBR81Zn/sLPQ0AoFl3lb J6GPQKwjdQT83O3o7PTq =lueP -----END PGP SIGNATURE----- --bM0CX4Vdg7uhh6lPXF0CT9wGinpMwhPMc--