From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Removal of unexec support from glibc malloc Date: Mon, 18 Jan 2016 22:10:09 +0000 Message-ID: References: <569CDB81.6040600@redhat.com> <569D3BE0.6050103@cs.ucla.edu> <569D4207.4060209@cs.ucla.edu> <83mvs2d5b2.fsf@gnu.org> <569D4590.4030203@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1148d398c9e6730529a3043d X-Trace: ger.gmane.org 1453155047 13283 80.91.229.3 (18 Jan 2016 22:10:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Jan 2016 22:10:47 +0000 (UTC) Cc: fweimer@redhat.com, Emacs-devel@gnu.org To: Daniel Colascione , Eli Zaretskii , Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 18 23:10:42 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 1aLI0W-0002u2-9o for ged-emacs-devel@m.gmane.org; Mon, 18 Jan 2016 23:10:40 +0100 Original-Received: from localhost ([::1]:33986 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLI0V-0002J8-1e for ged-emacs-devel@m.gmane.org; Mon, 18 Jan 2016 17:10:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45226) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLI0F-0002GU-TI for Emacs-devel@gnu.org; Mon, 18 Jan 2016 17:10:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLI0E-0002zL-Ns for Emacs-devel@gnu.org; Mon, 18 Jan 2016 17:10:23 -0500 Original-Received: from mail-wm0-x22e.google.com ([2a00:1450:400c:c09::22e]:34276) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLI0C-0002yB-T2; Mon, 18 Jan 2016 17:10:21 -0500 Original-Received: by mail-wm0-x22e.google.com with SMTP id u188so120812296wmu.1; Mon, 18 Jan 2016 14:10:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=mGd6sKRqJUf3Dz4LrhWXlUd2vQuhp6zaFK2ukxvC0tU=; b=BVXdDxPIOqVwJsP/uVAToWY6CoOCILeXaPlL8rQDnMRw4QrZ6/wFwpQ71vkHg5P7P5 uydjCpExbu+lb2g7MPSiB03466aKzdvC8lkLi31L/XGI/z5sczINFjntASdRT6TPkqBV uF0NZh09o8lUPv/HB3xs8wrYvRMucTwSSbAj++nbR2GeQrb4gxfO8C4+XW6IK/FMjsS1 H6vDrykrn+ID4HRwakhVpzhlDsnPk2VhGaaY5ppxT22wpG2yo/bTKbJbf9JjFGl0lNdp 4Iaw5WRQ5QGrhKDTVOpm9hCLTS3c9gg5mkBJW+t8iY/SbKM0jQ49xnpMZWJ/SXf2rsE/ L6VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=mGd6sKRqJUf3Dz4LrhWXlUd2vQuhp6zaFK2ukxvC0tU=; b=M3G72irNikW8n+D/67ZuJ4g9cuawEGntPx+eZDlNXc4+p/oTE7l/dhMKA1EbP+psT6 JTh24qjgKTZ564VOTi9wm+z6VCv9E12Bjz+c4FGNKK+o+wDhLY0e/OWpc62o/mowxcVt j106hid+B5HmFApFIV1FCC9hU9GbJ6G4kD7cxi5qix2gaXrJAy5IHnyTK+bM1lzaDMqF 6EBk1XMpPKEmK2ZtV4Hb/KCjlv9++KHvRLJReik9VtePaDapkWjUjsFWBMG4nG39gDWy wz8by27nNolZlKI+iAdopazP1RhU7be8M4Daclb/igqNHJeWHAmfn1tqAD83GdLY310g PPJA== X-Gm-Message-State: AG10YORzhc6jIX16LKVP5p4RdMBWNXLYYwXdIoQkDiFRGzBjvYctNw1NAQXYSr9Ds6NT9vXTPLoMea2phFOP4w== X-Received: by 10.28.60.68 with SMTP id j65mr15223612wma.33.1453155020296; Mon, 18 Jan 2016 14:10:20 -0800 (PST) In-Reply-To: <569D4590.4030203@dancol.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::22e 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:198301 Archived-At: --001a1148d398c9e6730529a3043d Content-Type: text/plain; charset=UTF-8 Daniel Colascione schrieb am Mo., 18. Jan. 2016 um 21:05 Uhr: > 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 > >> XEmacs does, which is to write out data and mmap it in later (sorry, > don't know > >> the details). There are other possibilities, e.g., have unexec write > out the > >> state in the form of C files that are compiled and linked in the usual > way to > >> build a faster-starting executable (this would be an Emacs API change, > though). > >> Any such changes would take some time to hack into something reliable > and > >> portable, and so will have to wait until after Emacs 25 is out. > > > > 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. > > > > 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). > > I completely agree. Also see the existing bugs https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20215 and https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20868. Does anybody have a rough estimate what would be required to make the dumper really portable? --001a1148d398c9e6730529a3043d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Daniel= Colascione <dancol@dancol.org&= gt; schrieb am Mo., 18. Jan. 2016 um 21:05=C2=A0Uhr:
On 01/18/2016 12:02 PM, Eli Zaretskii wrote:
>> From: Paul Eggert <eggert@cs.ucla.edu>
>> Date: Mon, 18 Jan 2016 11:50:31 -0800
>>
>> Emacs could live without the current unexec in a semi-portable way= by doing what
>> XEmacs does, which is to write out data and mmap it in later (sorr= y, don't know
>> the details). There are other possibilities, e.g., have unexec wri= te out the
>> state in the form of C files that are compiled and linked in the u= sual way to
>> build a faster-starting executable (this would be an Emacs API cha= nge, though).
>> Any such changes would take some time to hack into something relia= ble and
>> portable, and so will have to wait until after Emacs 25 is out. >
> There's also what the MS-Windows port does (temacs allocates off a=
> static array), which AFAIK is entirely portable, and doesn't requi= re
> mmap.=C2=A0 See w32heap.c.
>

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).


Does anybody have a ro= ugh estimate what would be required to make the dumper really portable?=C2= =A0
--001a1148d398c9e6730529a3043d--