GNU bug report logs - #23529
Request for fixing randomize_va_space build issues

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Severity: important; Reported by: Philippe Vaucher <philippe.vaucher@HIDDEN>; merged with #13964; dated Fri, 13 May 2016 12:20:02 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 11 Sep 2016 17:19:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 11 13:19:56 2016
Received: from localhost ([127.0.0.1]:56678 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bj8Q7-0003vV-To
	for submit <at> debbugs.gnu.org; Sun, 11 Sep 2016 13:19:56 -0400
Received: from eggs.gnu.org ([208.118.235.92]:44840)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1bj8Q5-0003vI-HI
 for 23529 <at> debbugs.gnu.org; Sun, 11 Sep 2016 13:19:53 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1bj8Px-0001eD-DQ
 for 23529 <at> debbugs.gnu.org; Sun, 11 Sep 2016 13:19:48 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50682)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1bj8Px-0001dx-9y; Sun, 11 Sep 2016 13:19:45 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1308
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1bj8Pt-0000j9-CK; Sun, 11 Sep 2016 13:19:43 -0400
Date: Sun, 11 Sep 2016 20:19:28 +0300
Message-Id: <83wpii9wwv.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <2112c911-8613-01fd-2ec5-dfc29002acce@HIDDEN> (message from
 Paul Eggert on Sun, 11 Sep 2016 09:59:52 -0700)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN> <83eg4vab5o.fsf@HIDDEN>
 <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN> <831t0va8br.fsf@HIDDEN>
 <478e7c97-9339-5072-f9c1-ec67a45113aa@HIDDEN> <83h99p8wbh.fsf@HIDDEN>
 <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@HIDDEN> <83d1kd8qb7.fsf@HIDDEN>
 <c74dafef-53ff-7a6e-d905-2583c1a78451@HIDDEN> <838tv18mnj.fsf@HIDDEN>
 <ebbb21e2-5c26-ae25-0adb-74f14b395b4c@HIDDEN> <83eg4sap3t.fsf@HIDDEN>
 <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@HIDDEN> <83wpik8f18.fsf@HIDDEN>
 <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@HIDDEN> <83k2ek83b7.fsf@HIDDEN>
 <24612cc1-cb72-511f-7d52-bb62101906ae@HIDDEN> <83fup6bguo.fsf@HIDDEN> 
 <2112c911-8613-01fd-2ec5-dfc29002acce@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -7.2 (-------)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -7.2 (-------)

> Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
> From: Paul Eggert <eggert@HIDDEN>
> Date: Sun, 11 Sep 2016 09:59:52 -0700
> 
> Eli Zaretskii wrote:
> 
> > What do you mean by
> > "relocating objects", and why would we need to do that as part of
> > un-dumping?
> 
> Objects in the new Emacs might have different addresses from objects in the old 
> Emacs, due to address randomization.

Yes, but I don't think we will see them in the dumped data, except as
results of DEFVAR etc., which will have to be fixed up anyway.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 11 Sep 2016 17:00:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 11 13:00:02 2016
Received: from localhost ([127.0.0.1]:56662 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bj86r-0003Qk-K7
	for submit <at> debbugs.gnu.org; Sun, 11 Sep 2016 13:00:01 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:34476)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1bj86p-0003Q6-Pg
 for 23529 <at> debbugs.gnu.org; Sun, 11 Sep 2016 13:00:00 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id F3ACE160972;
 Sun, 11 Sep 2016 09:59:53 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id IoLEwoSYlyy3; Sun, 11 Sep 2016 09:59:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 490A6161117;
 Sun, 11 Sep 2016 09:59:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id cA2z07Youq2C; Sun, 11 Sep 2016 09:59:53 -0700 (PDT)
Received: from [192.168.1.9] (unknown [100.32.155.148])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 23F75160972;
 Sun, 11 Sep 2016 09:59:53 -0700 (PDT)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Eli Zaretskii <eliz@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN> <83eg4vab5o.fsf@HIDDEN>
 <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN> <831t0va8br.fsf@HIDDEN>
 <478e7c97-9339-5072-f9c1-ec67a45113aa@HIDDEN> <83h99p8wbh.fsf@HIDDEN>
 <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@HIDDEN> <83d1kd8qb7.fsf@HIDDEN>
 <c74dafef-53ff-7a6e-d905-2583c1a78451@HIDDEN> <838tv18mnj.fsf@HIDDEN>
 <ebbb21e2-5c26-ae25-0adb-74f14b395b4c@HIDDEN> <83eg4sap3t.fsf@HIDDEN>
 <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@HIDDEN> <83wpik8f18.fsf@HIDDEN>
 <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@HIDDEN> <83k2ek83b7.fsf@HIDDEN>
 <24612cc1-cb72-511f-7d52-bb62101906ae@HIDDEN> <83fup6bguo.fsf@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <2112c911-8613-01fd-2ec5-dfc29002acce@HIDDEN>
Date: Sun, 11 Sep 2016 09:59:52 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <83fup6bguo.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.2 (--)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.2 (--)

Eli Zaretskii wrote:

> What do you mean by
> "relocating objects", and why would we need to do that as part of
> un-dumping?

Objects in the new Emacs might have different addresses from objects in the old 
Emacs, due to address randomization.

>>     What about disabling randomization for the temacs run?
>>
>> That is yet another low-level thing to configure, and to get right in new ports.
>
> We already have that in Emacs, don't we?

Yes, and that's one of the problems that we should fix. It causes us to run into 
portability problems. It's still not clear that the current implementation will 
actually work on POSIXish systems. We are on (or over) the edge of portability 
here, and we need to get off.

> No, this point started with me saying dumping and reading dumped data
> with fixups is relatively easy, and you objecting saying address
> randomizations will defeat that.  Now we agree that it's a tangential
> issue unrelated to my proposal.

We don't agree.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 11 Sep 2016 15:23:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 11 11:23:39 2016
Received: from localhost ([127.0.0.1]:56556 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bj6bb-0000yX-9f
	for submit <at> debbugs.gnu.org; Sun, 11 Sep 2016 11:23:39 -0400
Received: from eggs.gnu.org ([208.118.235.92]:52016)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1bj6bZ-0000yK-7C
 for 23529 <at> debbugs.gnu.org; Sun, 11 Sep 2016 11:23:37 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1bj6bQ-0002Oc-W5
 for 23529 <at> debbugs.gnu.org; Sun, 11 Sep 2016 11:23:32 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48978)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1bj6bQ-0002OP-Sg; Sun, 11 Sep 2016 11:23:28 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1134
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1bj6bO-0007Y7-Ts; Sun, 11 Sep 2016 11:23:27 -0400
Date: Sun, 11 Sep 2016 18:23:27 +0300
Message-Id: <83fup6bguo.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <24612cc1-cb72-511f-7d52-bb62101906ae@HIDDEN> (message from
 Paul Eggert on Sat, 10 Sep 2016 16:01:28 -0700)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN> <83eg4vab5o.fsf@HIDDEN>
 <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN> <831t0va8br.fsf@HIDDEN>
 <478e7c97-9339-5072-f9c1-ec67a45113aa@HIDDEN> <83h99p8wbh.fsf@HIDDEN>
 <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@HIDDEN> <83d1kd8qb7.fsf@HIDDEN>
 <c74dafef-53ff-7a6e-d905-2583c1a78451@HIDDEN> <838tv18mnj.fsf@HIDDEN>
 <ebbb21e2-5c26-ae25-0adb-74f14b395b4c@HIDDEN> <83eg4sap3t.fsf@HIDDEN>
 <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@HIDDEN> <83wpik8f18.fsf@HIDDEN>
 <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@HIDDEN> <83k2ek83b7.fsf@HIDDEN>
 <24612cc1-cb72-511f-7d52-bb62101906ae@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -7.2 (-------)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -7.2 (-------)

> Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
> From: Paul Eggert <eggert@HIDDEN>
> Date: Sat, 10 Sep 2016 16:01:28 -0700
> 
>     Conservative stack marking is for Lisp objects held in variables on
>     the stack.  Those objects cannot be relevant to dumping
> 
> Yes, but the conservativeness of the marking phase means Emacs cannot relocate objects.

I don't understand how this is relevant.  What do you mean by
"relocating objects", and why would we need to do that as part of
un-dumping?

>     If mainline libc allows such control on its memory
>     allocation back-end, it is better to use that than rely on our own
>     replacement allocator.
> 
> Although that might be better than what we're doing, better yet would be to not fiddle with such internal details of malloc at all.

Yes, and it's better not to fiddle with Emacs at all, if all we want
is simple C programs.

>     What about disabling randomization for the temacs run?
> 
> That is yet another low-level thing to configure, and to get right in new ports.

We already have that in Emacs, don't we?

> The approach I'm suggesting does not rely on disabling randomization.

It has other costs, though.  A tradeoff should consider them all, not
one by one.

> This point is a tangent to its containing thread, as the thread in question is about whether compilers and linkers can relocate pointers for us. The code example establishes that compilers and linkers can do so, regardless of whether Emacs is using that capability now. 

No, this point started with me saying dumping and reading dumped data
with fixups is relatively easy, and you objecting saying address
randomizations will defeat that.  Now we agree that it's a tangential
issue unrelated to my proposal.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 10 Sep 2016 23:01:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 10 19:01:38 2016
Received: from localhost ([127.0.0.1]:55828 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1birHF-0006Kd-Py
	for submit <at> debbugs.gnu.org; Sat, 10 Sep 2016 19:01:37 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:34606)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1birHE-0006KR-DB
 for 23529 <at> debbugs.gnu.org; Sat, 10 Sep 2016 19:01:36 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9A099160D51;
 Sat, 10 Sep 2016 16:01:29 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id fC1m6FTeCpOu; Sat, 10 Sep 2016 16:01:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id CB3171611FD;
 Sat, 10 Sep 2016 16:01:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id 8q4ukLva8Hni; Sat, 10 Sep 2016 16:01:28 -0700 (PDT)
Received: from [192.168.1.9] (unknown [100.32.155.148])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id A21F2160D51;
 Sat, 10 Sep 2016 16:01:28 -0700 (PDT)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Eli Zaretskii <eliz@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN> <83eg4vab5o.fsf@HIDDEN>
 <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN> <831t0va8br.fsf@HIDDEN>
 <478e7c97-9339-5072-f9c1-ec67a45113aa@HIDDEN> <83h99p8wbh.fsf@HIDDEN>
 <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@HIDDEN> <83d1kd8qb7.fsf@HIDDEN>
 <c74dafef-53ff-7a6e-d905-2583c1a78451@HIDDEN> <838tv18mnj.fsf@HIDDEN>
 <ebbb21e2-5c26-ae25-0adb-74f14b395b4c@HIDDEN> <83eg4sap3t.fsf@HIDDEN>
 <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@HIDDEN> <83wpik8f18.fsf@HIDDEN>
 <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@HIDDEN> <83k2ek83b7.fsf@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <24612cc1-cb72-511f-7d52-bb62101906ae@HIDDEN>
Date: Sat, 10 Sep 2016 16:01:28 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <83k2ek83b7.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.3 (-)

Eli Zaretskii wrote:

> Conservative stack marking is for Lisp objects held in variables on
> the stack.  Those objects cannot be relevant to dumping

Yes, but the conservativeness of the marking phase means Emacs cannot rel=
ocate=20
objects. This is true regardless of whether the objects-that-can't-be-mov=
ed=20
reside on the stack or on the heap.

> If mainline libc allows such control on its memory
> allocation back-end, it is better to use that than rely on our own
> replacement allocator.

Although that might be better than what we're doing, better yet would be =
to not=20
fiddle with such internal details of malloc at all.

> What about disabling randomization for the temacs run?

That is yet another low-level thing to configure, and to get right in new=
 ports.=20
The approach I'm suggesting does not rely on disabling randomization.

> I don't think we do that in code that runs in temacs.

This point is a tangent to its containing thread, as the thread in questi=
on is=20
about whether compilers and linkers can relocate pointers for us. The cod=
e=20
example establishes that compilers and linkers can do so, regardless of w=
hether=20
Emacs is using that capability now.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 10 Sep 2016 10:20:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 10 06:20:02 2016
Received: from localhost ([127.0.0.1]:55156 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bifOD-0006pR-3U
	for submit <at> debbugs.gnu.org; Sat, 10 Sep 2016 06:20:01 -0400
Received: from eggs.gnu.org ([208.118.235.92]:33218)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1bifOB-0006pF-M8
 for 23529 <at> debbugs.gnu.org; Sat, 10 Sep 2016 06:20:00 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1bifO2-0007jC-0J
 for 23529 <at> debbugs.gnu.org; Sat, 10 Sep 2016 06:19:54 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58105)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1bifO1-0007j8-T8; Sat, 10 Sep 2016 06:19:49 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2444
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1bifNy-00073e-Px; Sat, 10 Sep 2016 06:19:48 -0400
Date: Sat, 10 Sep 2016 13:19:40 +0300
Message-Id: <83k2ek83b7.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@HIDDEN> (message from
 Paul Eggert on Sat, 10 Sep 2016 00:52:33 -0700)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN> <83eg4vab5o.fsf@HIDDEN>
 <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN> <831t0va8br.fsf@HIDDEN>
 <478e7c97-9339-5072-f9c1-ec67a45113aa@HIDDEN> <83h99p8wbh.fsf@HIDDEN>
 <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@HIDDEN> <83d1kd8qb7.fsf@HIDDEN>
 <c74dafef-53ff-7a6e-d905-2583c1a78451@HIDDEN> <838tv18mnj.fsf@HIDDEN>
 <ebbb21e2-5c26-ae25-0adb-74f14b395b4c@HIDDEN> <83eg4sap3t.fsf@HIDDEN>
 <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@HIDDEN> <83wpik8f18.fsf@HIDDEN>
 <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -6.3 (------)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.3 (------)

> Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
> From: Paul Eggert <eggert@HIDDEN>
> Date: Sat, 10 Sep 2016 00:52:33 -0700
> 
> Eli Zaretskii wrote:
> 
> > I fail to see why it would be hard to maintain that portably.  Those
> > data structures are entirely our design and implementatio
> 
> If it were *that* easy to do, the garbage collector would be doing it. It does 
> not. It uses conservative collection, which is easier as it does not relocate 
> pointers.

Conservative stack marking is for Lisp objects held in variables on
the stack.  Those objects cannot be relevant to dumping, because
stack-based variables disappear without a trace when we dump _today_,
and we don't have any problems with that.

GC cannot disregard stack-based values, without asking the programmer
to use GCPRO.

> > temacs is not a program that needs to run for prolonged time
> > intervals, its only purpose is to produce the data that the un-dumped
> > Emacs will use.  So whether its malloc implementation is strong enough
> > by today's standards is not a relevant question.  What matters is is
> > it good enough for what temacs should do before it exits.
> 
> Fair enough. Still this hybrid-implementation approach, where the code uses one 
> malloc implementation before dumping, and a different one after, is an extra 
> complexity that makes it harder to understand and maintain Emacs. It would be 
> better to remove this hack, and we should not be piling even more gingerbread 
> atop it.

I agree.  If mainline libc allows such control on its memory
allocation back-end, it is better to use that than rely on our own
replacement allocator.

> > we could have a variable that would force using the
> > pre-dump malloc in emacs.
> 
> That would be still more complexity and state.
> 
> >> Plus, it assumes sbrk, which is backward-looking.
> >
> > What part assumes sbrk?
> 
> The current gmalloc implementation assumes the sbrk model, and operates poorly 
> (if at all) when the underlying implementation uses address randomization.

What about disabling randomization for the temacs run?

> > But we don't do these things in our code, so how is this relevant to
> > this discussion?
> 
> We do almost all of that example in our code already. Most of the example was 
> taken from lisp.h (with some simplifications just for the example; the actual 
> implementation would be based on the current lisp.h).

No, I don't think we do that in code that runs in temacs.  If you see
such code, which defines statically-allocated Lisp objects that need
to survive dumping, please point me to it.

In any case, even if such static Lisp objects exist, they just need to
be fixed as well, as part of un-dumping.

> The example demonstrates 
> that compilers and linkers can relocate tagged Lisp pointers themselves, which 
> means we don't have to do that ourselves.

You don't need to convince me that a linker can relocate addresses, I
know that.  Our differences of opinions are not about that.

> > One example is string_blocks, which we
> > use to maintain Lisp strings.  Surely, this structure will be in a
> > single "block" under memory randomization, right?
> 
> That would be simpler, at least at first. But it's not the only possibility. For 
> example, we could put each pure string in a separate block.

I don't see why we would want to, it would mean too many
disadvantages.  But even if we did, it just means separate fixup value
for each block, that's all.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 10 Sep 2016 07:52:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 10 03:52:47 2016
Received: from localhost ([127.0.0.1]:55114 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bid5j-0001mb-Ft
	for submit <at> debbugs.gnu.org; Sat, 10 Sep 2016 03:52:47 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:35454)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1bid5h-0001mN-NQ
 for 23529 <at> debbugs.gnu.org; Sat, 10 Sep 2016 03:52:46 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id E839C160D6F;
 Sat, 10 Sep 2016 00:52:38 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id gNPy8hlwU4rf; Sat, 10 Sep 2016 00:52:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 1E928160E48;
 Sat, 10 Sep 2016 00:52:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id 8NNBkEQazVP4; Sat, 10 Sep 2016 00:52:38 -0700 (PDT)
Received: from [192.168.1.9] (unknown [100.32.155.148])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id EF05E160D6F;
 Sat, 10 Sep 2016 00:52:37 -0700 (PDT)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Eli Zaretskii <eliz@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN> <83eg4vab5o.fsf@HIDDEN>
 <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN> <831t0va8br.fsf@HIDDEN>
 <478e7c97-9339-5072-f9c1-ec67a45113aa@HIDDEN> <83h99p8wbh.fsf@HIDDEN>
 <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@HIDDEN> <83d1kd8qb7.fsf@HIDDEN>
 <c74dafef-53ff-7a6e-d905-2583c1a78451@HIDDEN> <838tv18mnj.fsf@HIDDEN>
 <ebbb21e2-5c26-ae25-0adb-74f14b395b4c@HIDDEN> <83eg4sap3t.fsf@HIDDEN>
 <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@HIDDEN> <83wpik8f18.fsf@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@HIDDEN>
Date: Sat, 10 Sep 2016 00:52:33 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <83wpik8f18.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.3 (-)

Eli Zaretskii wrote:

> I fail to see why it would be hard to maintain that portably.  Those
> data structures are entirely our design and implementatio

If it were *that* easy to do, the garbage collector would be doing it. It=
 does=20
not. It uses conservative collection, which is easier as it does not relo=
cate=20
pointers.

> temacs is not a program that needs to run for prolonged time
> intervals, its only purpose is to produce the data that the un-dumped
> Emacs will use.  So whether its malloc implementation is strong enough
> by today's standards is not a relevant question.  What matters is is
> it good enough for what temacs should do before it exits.

Fair enough. Still this hybrid-implementation approach, where the code us=
es one=20
malloc implementation before dumping, and a different one after, is an ex=
tra=20
complexity that makes it harder to understand and maintain Emacs. It woul=
d be=20
better to remove this hack, and we should not be piling even more gingerb=
read=20
atop it.

> we could have a variable that would force using the
> pre-dump malloc in emacs.

That would be still more complexity and state.

>> Plus, it assumes sbrk, which is backward-looking.
>
> What part assumes sbrk?

The current gmalloc implementation assumes the sbrk model, and operates p=
oorly=20
(if at all) when the underlying implementation uses address randomization=
. We=20
are already at the edge of portability here; the fact that it works at al=
l on=20
modern GNU/Linux is a bit of an accident, requires mysterious tweaks=20
occasionally at the C level, and there's no guarantee it will continue to=
 work.

> we can still implement undump using a data
> file, but it will make our job slightly more complex, as we'd need to
> collect the data allocated off the heap before dumping it.  Not rocket
> science, either.

None of this is rocket science! But it is unnecessary complexity.

> But we don't do these things in our code, so how is this relevant to
> this discussion?

We do almost all of that example in our code already. Most of the example=
 was=20
taken from lisp.h (with some simplifications just for the example; the ac=
tual=20
implementation would be based on the current lisp.h). The example demonst=
rates=20
that compilers and linkers can relocate tagged Lisp pointers themselves, =
which=20
means we don't have to do that ourselves.

> One example is string_blocks, which we
> use to maintain Lisp strings.  Surely, this structure will be in a
> single "block" under memory randomization, right?

That would be simpler, at least at first. But it's not the only possibili=
ty. For=20
example, we could put each pure string in a separate block.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 10 Sep 2016 06:13:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 10 02:13:32 2016
Received: from localhost ([127.0.0.1]:55069 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bibXg-0007uN-IH
	for submit <at> debbugs.gnu.org; Sat, 10 Sep 2016 02:13:32 -0400
Received: from eggs.gnu.org ([208.118.235.92]:57166)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1bibXf-0007uB-Da
 for 23529 <at> debbugs.gnu.org; Sat, 10 Sep 2016 02:13:31 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1bibXW-0007V5-40
 for 23529 <at> debbugs.gnu.org; Sat, 10 Sep 2016 02:13:26 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56297)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1bibXW-0007Uy-0k; Sat, 10 Sep 2016 02:13:22 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1751
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1bibXT-0000fO-VC; Sat, 10 Sep 2016 02:13:20 -0400
Date: Sat, 10 Sep 2016 09:13:18 +0300
Message-Id: <83twdo8ept.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Philippe Vaucher <philippe.vaucher@HIDDEN>
In-reply-to: <CAGK7Mr6SjD70sL+Ym1RVgHrfctOC4k2cyyGWeRY9rY4xd+u3bw@HIDDEN>
 (message from Philippe Vaucher on Fri, 9 Sep 2016 22:00:43 +0200)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN> <83eg4vab5o.fsf@HIDDEN>
 <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN> <831t0va8br.fsf@HIDDEN>
 <478e7c97-9339-5072-f9c1-ec67a45113aa@HIDDEN> <83h99p8wbh.fsf@HIDDEN>
 <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@HIDDEN> <83d1kd8qb7.fsf@HIDDEN>
 <c74dafef-53ff-7a6e-d905-2583c1a78451@HIDDEN> <838tv18mnj.fsf@HIDDEN> 
 <ebbb21e2-5c26-ae25-0adb-74f14b395b4c@HIDDEN>
 <CAGK7Mr6SjD70sL+Ym1RVgHrfctOC4k2cyyGWeRY9rY4xd+u3bw@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -6.3 (------)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, eggert@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.3 (------)

> From: Philippe Vaucher <philippe.vaucher@HIDDEN>
> Date: Fri, 9 Sep 2016 22:00:43 +0200
> Cc: Philipp Stephani <p.stephani2@HIDDEN>, 23529 <at> debbugs.gnu.org, 
> 	Eli Zaretskii <eliz@HIDDEN>
> 
> >> A typical non-trivial Emacs session takes several seconds, sometimes
> >> 25 or more, to start
> >
> > ?! That may be typical for *you*. It is not typical for me. On the six-year-old desktop at work that I'm using to
> type this message (hard disks, no flash) in normal mode, Emacs by default takes 1.2 seconds to start up.
> Even 1.2 seconds is too long, as I start up Emacs a lot.
> 
> I second that, most people load emacs in less than 7 seconds, and below 2 when they use use-package or
> equivalent. That is for emacs with 50+ packages.

Didn't I say "several seconds"?  Where's the contradiction?

Several seconds is a lot of time for modern CPUs, address fixup is a
rather cheap operation.  That's what the dynamic linker does every
time you load a shared library -- did you ever find that loading
annoyingly long?

> I agree with the spirit: we should try to simplify & modernify emacs. Adding something very custom sounds
> like another maintenance hell.

Excuse me, but how is relying on compilers and linkers more "modern"?

"Maintenance hell"?  Did you see how many changes in Emacs are done to
adapt Emacs to some particular compiler on some particular system?  I
suggest you take a look at "git log" (search for "Port "), keeping up
with that is no less "maintenance hell" than maintaining our own code.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 10 Sep 2016 06:06:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 10 02:06:43 2016
Received: from localhost ([127.0.0.1]:55065 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bibR4-0007kq-M3
	for submit <at> debbugs.gnu.org; Sat, 10 Sep 2016 02:06:42 -0400
Received: from eggs.gnu.org ([208.118.235.92]:56356)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1bibR3-0007kd-33
 for 23529 <at> debbugs.gnu.org; Sat, 10 Sep 2016 02:06:41 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1bibQt-0006HS-FL
 for 23529 <at> debbugs.gnu.org; Sat, 10 Sep 2016 02:06:36 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56241)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1bibQt-0006Gf-Bp; Sat, 10 Sep 2016 02:06:31 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1745
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1bibQr-0004U2-DC; Sat, 10 Sep 2016 02:06:29 -0400
Date: Sat, 10 Sep 2016 09:06:27 +0300
Message-Id: <83wpik8f18.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@HIDDEN> (message from
 Paul Eggert on Fri, 9 Sep 2016 12:59:16 -0700)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN> <83eg4vab5o.fsf@HIDDEN>
 <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN> <831t0va8br.fsf@HIDDEN>
 <478e7c97-9339-5072-f9c1-ec67a45113aa@HIDDEN> <83h99p8wbh.fsf@HIDDEN>
 <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@HIDDEN> <83d1kd8qb7.fsf@HIDDEN>
 <c74dafef-53ff-7a6e-d905-2583c1a78451@HIDDEN> <838tv18mnj.fsf@HIDDEN>
 <ebbb21e2-5c26-ae25-0adb-74f14b395b4c@HIDDEN> <83eg4sap3t.fsf@HIDDEN> 
 <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -6.3 (------)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.3 (------)

> Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
> From: Paul Eggert <eggert@HIDDEN>
> Date: Fri, 9 Sep 2016 12:59:16 -0700
> 
> On 09/09/2016 11:45 AM, Eli Zaretskii wrote:
> > All of those data structures are memory allocated for Lisp objects and
> > their supporting structures, with known structures, so we know exactly
> > which pointers need fixing.
> 
> Of course. But it's not trivial to fix them. It can be done, but it will 
> take code that will be hard to maintain portably.

I fail to see why it would be hard to maintain that portably.  Those
data structures are entirely our design and implementation, their
differences between platforms are almost non-existent.  Finding all
the pointers in them is almost trivial.

> > gmalloc is already implemented
> 
> Yes, and its problems are prompting this discussion. gmalloc was a fine 
> design for the 1980s but is not now.

temacs is not a program that needs to run for prolonged time
intervals, its only purpose is to produce the data that the un-dumped
Emacs will use.  So whether its malloc implementation is strong enough
by today's standards is not a relevant question.  What matters is is
it good enough for what temacs should do before it exits.

> > If there are libc's out there that allow the application to define its
> > own sbrk, then we could use that (we do on Windows).
> 
> The sbrk model is becoming less and less plausible.

Or whatever other back-end is used by malloc implementations, sbrk is
not an important detail.

> > If not, gmalloc
> > will be good enough for the temacs run; emacs will of course use the
> > normal libc allocators.
> 
> This would give up on redumping, no?

Not necessarily, we could have a variable that would force using the
pre-dump malloc in emacs.

> Plus, it assumes sbrk, which is backward-looking.

What part assumes sbrk?

> POSIX has withdrawn support for sbrk and there is 
> movement to deprecate it in C libraries due to security/robustness 
> concerns. This is something we should encourage, not run away from.

This is a wrong tree to bark up.  What we need is a malloc back-end
that will allow to allocate memory off an implementation-specified
memory block, that's all.

If we cannot have that (which would surprise me, since MS-Windows does
provide such a feature), we can still implement undump using a data
file, but it will make our job slightly more complex, as we'd need to
collect the data allocated off the heap before dumping it.  Not rocket
science, either.

> > What is a "block" in this context? Surely, a data structure with
> > linked pointers cannot be distributed between different "blocks",
> > since a linker will not know how to fixup each address, because it
> > doesn't understand the data structure.
> 
> It can be distributed between different "blocks", because we can tell 
> the compiler and linker the data structure. Here's a quick example with 
> two small "blocks" dX and dY (the actual code would differ, this is just 
> a proof of concept):
> 
>    /* Simplified version of lisp.h.  */
>    #include <stdint.h>
>    typedef intptr_t Lisp_Object;
>    enum { Lisp_Int0 = 2, Lisp_Cons = 3 /* ... */};
>    #define make_number(n) (((n) << 2) + Lisp_Int0)
>    #define TAG_PTR(tag, ptr) ((intptr_t) (ptr) + (tag))
>    #define Qnil ((Lisp_Object) 0)
>    struct Lisp_Cons { Lisp_Object car, cdr; };
> 
>    /* Define a statically-allocated pair x that is equal to (10).  */
>    struct Lisp_Cons dX = { make_number (10), Qnil };
>    #define x TAG_PTR (Lisp_Cons, &dX)
> 
>    /* Use x to build a statically-allocated list y that is equal to (5 
> 10).  */
>    struct Lisp_Cons dY = { make_number (5), x };
>    #define y TAG_PTR (Lisp_Cons, &dY)

But we don't do these things in our code, so how is this relevant to
this discussion?

What I had in mind is the data structures we use to support
maintenance of Lisp objects.  One example is string_blocks, which we
use to maintain Lisp strings.  Surely, this structure will be in a
single "block" under memory randomization, right?

> > We won't be able to use them as just compilers and linkers. We will
> > be using them for a job that is quite a bit more complex and
> > different.
> 
> No, this sort of thing is something that compilers and linkers do all 
> the time.

We won't know for sure until this is fully implemented.

Anyway, my take from this discussion is that we shouldn't give up so
easily on dumping data as a binary file, as that approach sounds to me
more future-proof than relying (again) on external technologies that
were not meant for this specific job.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 20:00:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 09 16:00:52 2016
Received: from localhost ([127.0.0.1]:54909 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1biRym-0008Fq-4J
	for submit <at> debbugs.gnu.org; Fri, 09 Sep 2016 16:00:52 -0400
Received: from mail-vk0-f54.google.com ([209.85.213.54]:35219)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philippe.vaucher@HIDDEN>) id 1biRyk-0008Fb-NF
 for 23529 <at> debbugs.gnu.org; Fri, 09 Sep 2016 16:00:51 -0400
Received: by mail-vk0-f54.google.com with SMTP id 16so58807359vko.2
 for <23529 <at> debbugs.gnu.org>; Fri, 09 Sep 2016 13:00:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to
 :cc; bh=3X/NBqEjYt1g5FE+F0j3r1N6os2ZBNX0ERstoRQ2EE4=;
 b=PMGsBm6W+zr23fkkAky32sRFJVX3HmZT0looxJ3Cpf4blqkqMKR0CmCStt+M4BXyCr
 EJQqlQ3U8ymoWDzmBnDE6T8/s33bKFB1zzHsiWenwsAvQ1uq7fhPmE+oQ6XYnCJXbzof
 PPAdPqmDYH29LrJsPLiCysse3JUwR3E6c0gRTVZyXBZeVTIFfYk251CCf1ZdL/Qp+ruF
 qLZmSDuGdibT3P2jo7i1p4RUcka+3rtnarSXe9PLdSBMLQXUIGTCgQMx9GPOrmqT/LtD
 BEgVsRyZdRMVY4DbqnEGo90iNpdJIxs5TC6jiv+VdcGTlpa2ENmeQ9FGr4+g+siO6ZIn
 i38w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:in-reply-to:references:from:date
 :message-id:subject:to:cc;
 bh=3X/NBqEjYt1g5FE+F0j3r1N6os2ZBNX0ERstoRQ2EE4=;
 b=OWTdFMVm+pLIjmKzsi7Om+LJvDmVTROQTiUOUWxrZm/bJHCMFrJIGBCYuctH4km/ro
 Sz5KxzWHYQqnkPl81eLaK0Qe5GyTVE4PbIrMW6/l92sntMeglNtbdGPRzqNDqaGraX/G
 poLvmrKLCJFz83MlSlCvwGJi9y0Ldq132GMyGNDeXMsuXgoxRSV2wMwxgdhY8ZSChEcb
 Ycm+69ogiBTT8lZJ9F4csHs2hwGkMO8GIFtyAoqUD0hy5RoyF23X2L+oW1QW2JawPcke
 1PCoA4O/OrudDtbHCJdlZnDcSj3VuBI/MrNpxGxM/Y4JkECzAhQoH3WyCZaS13byuV8V
 Q4VA==
X-Gm-Message-State: AE9vXwMnQqb2XSjGgP2kuy7y4Ith9U0/5yt5gHpjhihA0ygrHwyH8jFO7bK7UTJEu5nHqx2pzXORL6wslmaLnQ==
X-Received: by 10.31.50.70 with SMTP id y67mr3849177vky.48.1473451245023; Fri,
 09 Sep 2016 13:00:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.44.18 with HTTP; Fri, 9 Sep 2016 13:00:43 -0700 (PDT)
Received: by 10.103.44.18 with HTTP; Fri, 9 Sep 2016 13:00:43 -0700 (PDT)
In-Reply-To: <ebbb21e2-5c26-ae25-0adb-74f14b395b4c@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN> <83eg4vab5o.fsf@HIDDEN>
 <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN> <831t0va8br.fsf@HIDDEN>
 <478e7c97-9339-5072-f9c1-ec67a45113aa@HIDDEN> <83h99p8wbh.fsf@HIDDEN>
 <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@HIDDEN> <83d1kd8qb7.fsf@HIDDEN>
 <c74dafef-53ff-7a6e-d905-2583c1a78451@HIDDEN> <838tv18mnj.fsf@HIDDEN>
 <ebbb21e2-5c26-ae25-0adb-74f14b395b4c@HIDDEN>
From: Philippe Vaucher <philippe.vaucher@HIDDEN>
Date: Fri, 9 Sep 2016 22:00:43 +0200
Message-ID: <CAGK7Mr6SjD70sL+Ym1RVgHrfctOC4k2cyyGWeRY9rY4xd+u3bw@HIDDEN>
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Paul Eggert <eggert@HIDDEN>
Content-Type: multipart/alternative; boundary=001a114316d40db805053c189ae8
X-Spam-Score: 1.7 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: >> A typical non-trivial Emacs session takes several seconds,
 sometimes >> 25 or more, to start > > ?! That may be typical for *you*. It
 is not typical for me. On the six-year-old desktop at work that I'm using
 to type this message (hard disks, no flash) in normal mode, Emacs by default
 takes 1.2 seconds to start up. Even 1.2 seconds is too long, as I start up
 Emacs a lot. [...] 
 Content analysis details:   (1.7 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 2.4 RCVD_IN_SORBS_SPAM     RBL: SORBS: sender is a spam source
 [209.85.213.54 listed in dnsbl.sorbs.net]
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at http://www.dnswl.org/, low
 trust [209.85.213.54 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
 [209.85.213.54 listed in wl.mailspike.net]
 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
 (philippe.vaucher[at]gmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 HTML_MESSAGE           BODY: HTML included in message
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid
X-Debbugs-Envelope-To: 23529
Cc: Philipp Stephani <p.stephani2@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.7 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  >> A typical non-trivial Emacs session takes several seconds,
    sometimes >> 25 or more, to start > > ?! That may be typical for *you*. It
    is not typical for me. On the six-year-old desktop at work that I'm using
    to type this message (hard disks, no flash) in normal mode, Emacs by default
    takes 1.2 seconds to start up. Even 1.2 seconds is too long, as I start up
    Emacs a lot. [...] 
 
 Content analysis details:   (1.7 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  2.4 RCVD_IN_SORBS_SPAM     RBL: SORBS: sender is a spam source
                             [209.85.213.54 listed in dnsbl.sorbs.net]
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at http://www.dnswl.org/, low
                             trust
                             [209.85.213.54 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
                             [209.85.213.54 listed in wl.mailspike.net]
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail provider
                             (philippe.vaucher[at]gmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 HTML_MESSAGE           BODY: HTML included in message
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
  0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid

--001a114316d40db805053c189ae8
Content-Type: text/plain; charset=UTF-8

>> A typical non-trivial Emacs session takes several seconds, sometimes
>> 25 or more, to start
>
> ?!  That may be typical for *you*. It is not typical for me. On the
six-year-old desktop at work that I'm using to type this message (hard
disks, no flash) in normal mode, Emacs by default takes 1.2 seconds to
start up. Even 1.2 seconds is too long, as I start up Emacs a lot.

I second that, most people load emacs in less than 7 seconds, and below 2
when they use use-package or equivalent. That is for emacs with 50+
packages.

> And as long as we use them as compilers and linkers, we will be fine. We
got into the current mess because we went under the covers of the
underlying systems. That was reasonable in the 1980s when things were
simpler, but it is not reasonable now.

I agree with the spirit: we should try to simplify & modernify emacs.
Adding something very custom sounds like another maintenance hell.

Philippe

--001a114316d40db805053c189ae8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">&gt;&gt; A typical non-trivial Emacs session takes several s=
econds, sometimes<br>
&gt;&gt; 25 or more, to start<br>
&gt;<br>
&gt; ?!=C2=A0 That may be typical for *you*. It is not typical for me. On t=
he six-year-old desktop at work that I&#39;m using to type this message (ha=
rd disks, no flash) in normal mode, Emacs by default takes 1.2 seconds to s=
tart up. Even 1.2 seconds is too long, as I start up Emacs a lot.</p>
<p dir=3D"ltr">I second that, most people load emacs in less than 7 seconds=
, and below 2 when they use use-package or equivalent. That is for emacs wi=
th 50+ packages.</p>
<p dir=3D"ltr">&gt; And as long as we use them as compilers and linkers, we=
 will be fine. We got into the current mess because we went under the cover=
s of the underlying systems. That was reasonable in the 1980s when things w=
ere simpler, but it is not reasonable now.</p>
<p dir=3D"ltr">I agree with the spirit: we should try to simplify &amp; mod=
ernify emacs. Adding something very custom sounds like another maintenance =
hell.</p>
<p dir=3D"ltr">Philippe</p>

--001a114316d40db805053c189ae8--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 19:59:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 09 15:59:25 2016
Received: from localhost ([127.0.0.1]:54905 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1biRxM-0008CM-Ps
	for submit <at> debbugs.gnu.org; Fri, 09 Sep 2016 15:59:24 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:33922)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1biRxL-0008C4-EC
 for 23529 <at> debbugs.gnu.org; Fri, 09 Sep 2016 15:59:24 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9A0B116120B;
 Fri,  9 Sep 2016 12:59:17 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id niIdR9flfIBN; Fri,  9 Sep 2016 12:59:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id BEF79161222;
 Fri,  9 Sep 2016 12:59:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id syunJbxLs4OV; Fri,  9 Sep 2016 12:59:16 -0700 (PDT)
Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id A4BA016120B;
 Fri,  9 Sep 2016 12:59:16 -0700 (PDT)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Eli Zaretskii <eliz@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN> <83eg4vab5o.fsf@HIDDEN>
 <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN> <831t0va8br.fsf@HIDDEN>
 <478e7c97-9339-5072-f9c1-ec67a45113aa@HIDDEN> <83h99p8wbh.fsf@HIDDEN>
 <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@HIDDEN> <83d1kd8qb7.fsf@HIDDEN>
 <c74dafef-53ff-7a6e-d905-2583c1a78451@HIDDEN> <838tv18mnj.fsf@HIDDEN>
 <ebbb21e2-5c26-ae25-0adb-74f14b395b4c@HIDDEN> <83eg4sap3t.fsf@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@HIDDEN>
Date: Fri, 9 Sep 2016 12:59:16 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <83eg4sap3t.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.3 (-)

On 09/09/2016 11:45 AM, Eli Zaretskii wrote:
> All of those data structures are memory allocated for Lisp objects and
> their supporting structures, with known structures, so we know exactly
> which pointers need fixing.

Of course. But it's not trivial to fix them. It can be done, but it will 
take code that will be hard to maintain portably.

> gmalloc is already implemented

Yes, and its problems are prompting this discussion. gmalloc was a fine 
design for the 1980s but is not now.

> If there are libc's out there that allow the application to define its
> own sbrk, then we could use that (we do on Windows).

The sbrk model is becoming less and less plausible.

> If not, gmalloc
> will be good enough for the temacs run; emacs will of course use the
> normal libc allocators.

This would give up on redumping, no? Plus, it assumes sbrk, which is 
backward-looking. POSIX has withdrawn support for sbrk and there is 
movement to deprecate it in C libraries due to security/robustness 
concerns. This is something we should encourage, not run away from.

> What is a "block" in this context? Surely, a data structure with
> linked pointers cannot be distributed between different "blocks",
> since a linker will not know how to fixup each address, because it
> doesn't understand the data structure.

It can be distributed between different "blocks", because we can tell 
the compiler and linker the data structure. Here's a quick example with 
two small "blocks" dX and dY (the actual code would differ, this is just 
a proof of concept):

   /* Simplified version of lisp.h.  */
   #include <stdint.h>
   typedef intptr_t Lisp_Object;
   enum { Lisp_Int0 = 2, Lisp_Cons = 3 /* ... */};
   #define make_number(n) (((n) << 2) + Lisp_Int0)
   #define TAG_PTR(tag, ptr) ((intptr_t) (ptr) + (tag))
   #define Qnil ((Lisp_Object) 0)
   struct Lisp_Cons { Lisp_Object car, cdr; };

   /* Define a statically-allocated pair x that is equal to (10).  */
   struct Lisp_Cons dX = { make_number (10), Qnil };
   #define x TAG_PTR (Lisp_Cons, &dX)

   /* Use x to build a statically-allocated list y that is equal to (5 
10).  */
   struct Lisp_Cons dY = { make_number (5), x };
   #define y TAG_PTR (Lisp_Cons, &dY)


> We won't be able to use them as just compilers and linkers. We will
> be using them for a job that is quite a bit more complex and
> different.

No, this sort of thing is something that compilers and linkers do all 
the time.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 18:56:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 09 14:56:30 2016
Received: from localhost ([127.0.0.1]:54880 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1biQyU-0006UD-C5
	for submit <at> debbugs.gnu.org; Fri, 09 Sep 2016 14:56:30 -0400
Received: from eggs.gnu.org ([208.118.235.92]:45930)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1biQyT-0006U2-78
 for 23529 <at> debbugs.gnu.org; Fri, 09 Sep 2016 14:56:29 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1biQyK-0008IZ-U4
 for 23529 <at> debbugs.gnu.org; Fri, 09 Sep 2016 14:56:24 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49858)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1biQyK-0008IG-RG; Fri, 09 Sep 2016 14:56:20 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1265
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1biQyI-0007pJ-TT; Fri, 09 Sep 2016 14:56:19 -0400
Date: Fri, 09 Sep 2016 21:56:14 +0300
Message-Id: <83a8fgaomp.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Andreas Schwab <schwab@HIDDEN>
In-reply-to: <87sht9ncz9.fsf@HIDDEN> (message from Andreas Schwab on
 Fri, 09 Sep 2016 20:29:30 +0200)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN>
 <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN>
 <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN>
 <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN>
 <83eg4vab5o.fsf@HIDDEN>
 <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN>
 <831t0va8br.fsf@HIDDEN>
 <478e7c97-9339-5072-f9c1-ec67a45113aa@HIDDEN>
 <83h99p8wbh.fsf@HIDDEN> <87sht9ncz9.fsf@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -6.3 (------)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, eggert@HIDDEN, philippe.vaucher@HIDDEN,
 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.3 (------)

> From: Andreas Schwab <schwab@HIDDEN>
> Cc: Paul Eggert <eggert@HIDDEN>,  p.stephani2@HIDDEN,  philippe.vaucher@HIDDEN,  23529 <at> debbugs.gnu.org
> Date: Fri, 09 Sep 2016 20:29:30 +0200
> 
> On Sep 09 2016, Eli Zaretskii <eliz@HIDDEN> wrote:
> 
> > defsubr does that, but fixing the address of the function after
> > loading the dumped data is also very simple: for each defsubr, rewrite
> > its function pointer.
> 
> Function pointers are difficult to handle, especially on architectures
> that use function descriptors.  That's why the "portable" dumper of
> xemacs doesn't work on ia64: it lumps together function and data
> pointers.

Sorry, I don't understand: does defsubr work on ia64?  If so, doing in
emacs just the last part of it, which stores the function pointer,
should also work, right?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 18:46:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 09 14:46:33 2016
Received: from localhost ([127.0.0.1]:54876 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1biQor-0006Fj-Ac
	for submit <at> debbugs.gnu.org; Fri, 09 Sep 2016 14:46:33 -0400
Received: from eggs.gnu.org ([208.118.235.92]:43543)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1biQop-0006FX-CZ
 for 23529 <at> debbugs.gnu.org; Fri, 09 Sep 2016 14:46:31 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1biQof-0005g5-LX
 for 23529 <at> debbugs.gnu.org; Fri, 09 Sep 2016 14:46:25 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49742)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1biQof-0005fx-Hu; Fri, 09 Sep 2016 14:46:21 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1259
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1biQob-0006nc-DO; Fri, 09 Sep 2016 14:46:20 -0400
Date: Fri, 09 Sep 2016 21:45:58 +0300
Message-Id: <83eg4sap3t.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <ebbb21e2-5c26-ae25-0adb-74f14b395b4c@HIDDEN> (message from
 Paul Eggert on Fri, 9 Sep 2016 09:16:39 -0700)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN> <83eg4vab5o.fsf@HIDDEN>
 <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN> <831t0va8br.fsf@HIDDEN>
 <478e7c97-9339-5072-f9c1-ec67a45113aa@HIDDEN> <83h99p8wbh.fsf@HIDDEN>
 <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@HIDDEN> <83d1kd8qb7.fsf@HIDDEN>
 <c74dafef-53ff-7a6e-d905-2583c1a78451@HIDDEN> <838tv18mnj.fsf@HIDDEN> 
 <ebbb21e2-5c26-ae25-0adb-74f14b395b4c@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -6.3 (------)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.3 (------)

> Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
> From: Paul Eggert <eggert@HIDDEN>
> Date: Fri, 9 Sep 2016 09:16:39 -0700
> 
> On 09/09/2016 02:09 AM, Eli Zaretskii wrote:
> >
> > Can you elaborate about the other ways you had in mind?
> 
> The best way to elaborate this is to write code. That being said, there 
> are a lot of pointers in the data structures of (e.g.) alloc.c and they 
> need to be saved and restored and demangled in the process.

All of those data structures are memory allocated for Lisp objects and
their supporting structures, with known structures, so we know exactly
which pointers need fixing.

> > What I had in mind is just a single 'write' (resp. 'read') call for
> > any contiguous region of memory.  (For best results, we will probably
> > want to use gmalloc so that it allocates memory off a single array we
> > define, so that we have fewer regions to write and read.)
> 
> That is exactly the wrong way to go. We should not implement our own low 
> level memory allocator again!

gmalloc is already implemented.

If there are libc's out there that allow the application to define its
own sbrk, then we could use that (we do on Windows).  If not, gmalloc
will be good enough for the temacs run; emacs will of course use the
normal libc allocators.

> Memory allocation is getting fancier and fancier internally in glibc
> and in other C libraries, for both performance and
> security/robustness reasons, and we shouldn't be wasting our
> development resources trying to keep up.

We will use libc in emacs.

> > By "pay" I meant the development, debugging, and maintenance costs,
> > not the run-time costs.
> 
> I meant both.

Each one is a different tradeoff.

> > A typical non-trivial Emacs session takes several seconds, sometimes
> > 25 or more, to start
> 
> ?!  That may be typical for *you*. It is not typical for me. On the 
> six-year-old desktop at work that I'm using to type this message (hard 
> disks, no flash) in normal mode, Emacs by default takes 1.2 seconds to 
> start up.

You have a small .emacs, I guess.

Anyway, even 1.2 sec is an eternity for the job at hand.  I don't see
a problem.

> > Their
> > developers could easily decide that these jobs don't need to be
> > supported
> 
> That's not likely. C compilers are commonly used as back ends for other 
> systems. Compiler writers take that part of the job seriously.

Yes, we used to think that back when unexec was implemented.

> > all you need is to fixup the pointers
> > in the dumped data accordingly.  Since the final effect of the
> > randomization is just to change the addresses by some fixed amount,
> No, every block is put into a random location.

What is a "block" in this context?  Surely, a data structure with
linked pointers cannot be distributed between different "blocks",
since a linker will not know how to fixup each address, because it
doesn't understand the data structure.  So I think you are talking
about an issue that will not affect us.  If that's not so, please do
describe the details, please don't hide behind "easier to write the
code" argument, because this issue is IMO of the utmost importance for
the future of Emacs.

> Worse, you have to know where the pointers are.

We know.

> > They develop compilers and linkers, not tools to
> > undump Emacs.
> 
> And as long as we use them as compilers and linkers, we will be
> fine.

We won't be able to use them as just compilers and linkers.  We will
be using them for a job that is quite a bit more complex and
different.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 18:29:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 09 14:29:36 2016
Received: from localhost ([127.0.0.1]:54870 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1biQYR-0005pC-Q8
	for submit <at> debbugs.gnu.org; Fri, 09 Sep 2016 14:29:36 -0400
Received: from mail-out.m-online.net ([212.18.0.9]:38471)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <whitebox@HIDDEN>) id 1biQYP-0005p4-Hn
 for 23529 <at> debbugs.gnu.org; Fri, 09 Sep 2016 14:29:34 -0400
Received: from frontend01.mail.m-online.net (unknown [192.168.8.182])
 by mail-out.m-online.net (Postfix) with ESMTP id 3sW5Mc0HSdz3hj25;
 Fri,  9 Sep 2016 20:29:31 +0200 (CEST)
Received: from localhost (dynscan1.mnet-online.de [192.168.6.68])
 by mail.m-online.net (Postfix) with ESMTP id 3sW5Mb4Rcbzvldb;
 Fri,  9 Sep 2016 20:29:31 +0200 (CEST)
X-Virus-Scanned: amavisd-new at mnet-online.de
Received: from mail.mnet-online.de ([192.168.8.182])
 by localhost (dynscan1.mail.m-online.net [192.168.6.68]) (amavisd-new,
 port 10024)
 with ESMTP id zIHB8r6LG9T3; Fri,  9 Sep 2016 20:29:30 +0200 (CEST)
X-Auth-Info: WEizePKOiXFx1NkcejbwOcWFG3XK+Nz8cVXI7RSsivJVbQq6fydfdEQTc5eqNyeS
Received: from igel.home (ppp-88-217-26-106.dynamic.mnet-online.de
 [88.217.26.106]) by mail.mnet-online.de (Postfix) with ESMTPA;
 Fri,  9 Sep 2016 20:29:30 +0200 (CEST)
Received: by igel.home (Postfix, from userid 1000)
 id 3E32F2C4DB3; Fri,  9 Sep 2016 20:29:30 +0200 (CEST)
From: Andreas Schwab <schwab@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN>
 <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN>
 <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN>
 <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN>
 <83eg4vab5o.fsf@HIDDEN>
 <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN>
 <831t0va8br.fsf@HIDDEN>
 <478e7c97-9339-5072-f9c1-ec67a45113aa@HIDDEN>
 <83h99p8wbh.fsf@HIDDEN>
X-Yow: I'm pretending I'm pulling in a TROUT!  Am I doing it correctly??
Date: Fri, 09 Sep 2016 20:29:30 +0200
In-Reply-To: <83h99p8wbh.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 09 Sep
 2016 08:40:50 +0300")
Message-ID: <87sht9ncz9.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, Paul Eggert <eggert@HIDDEN>,
 philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

On Sep 09 2016, Eli Zaretskii <eliz@HIDDEN> wrote:

> defsubr does that, but fixing the address of the function after
> loading the dumped data is also very simple: for each defsubr, rewrite
> its function pointer.

Function pointers are difficult to handle, especially on architectures
that use function descriptors.  That's why the "portable" dumper of
xemacs doesn't work on ia64: it lumps together function and data
pointers.

Andreas.

-- 
Andreas Schwab, schwab@HIDDEN
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 16:16:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 09 12:16:50 2016
Received: from localhost ([127.0.0.1]:54814 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1biOTy-0007lp-8s
	for submit <at> debbugs.gnu.org; Fri, 09 Sep 2016 12:16:50 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:55490)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1biOTw-0007lc-45
 for 23529 <at> debbugs.gnu.org; Fri, 09 Sep 2016 12:16:48 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id EFE6B161227;
 Fri,  9 Sep 2016 09:16:40 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id S11q7aGh_WmQ; Fri,  9 Sep 2016 09:16:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 27577161226;
 Fri,  9 Sep 2016 09:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id y49YHMnqr6Qs; Fri,  9 Sep 2016 09:16:40 -0700 (PDT)
Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 0BF11161222;
 Fri,  9 Sep 2016 09:16:40 -0700 (PDT)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Eli Zaretskii <eliz@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN> <83eg4vab5o.fsf@HIDDEN>
 <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN> <831t0va8br.fsf@HIDDEN>
 <478e7c97-9339-5072-f9c1-ec67a45113aa@HIDDEN> <83h99p8wbh.fsf@HIDDEN>
 <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@HIDDEN> <83d1kd8qb7.fsf@HIDDEN>
 <c74dafef-53ff-7a6e-d905-2583c1a78451@HIDDEN> <838tv18mnj.fsf@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <ebbb21e2-5c26-ae25-0adb-74f14b395b4c@HIDDEN>
Date: Fri, 9 Sep 2016 09:16:39 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <838tv18mnj.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.3 (-)

On 09/09/2016 02:09 AM, Eli Zaretskii wrote:
>
> Can you elaborate about the other ways you had in mind?

The best way to elaborate this is to write code. That being said, there 
are a lot of pointers in the data structures of (e.g.) alloc.c and they 
need to be saved and restored and demangled in the process.

> What I had in mind is just a single 'write' (resp. 'read') call for
> any contiguous region of memory.  (For best results, we will probably
> want to use gmalloc so that it allocates memory off a single array we
> define, so that we have fewer regions to write and read.)

That is exactly the wrong way to go. We should not implement our own low 
level memory allocator again! Memory allocation is getting fancier and 
fancier internally in glibc and in other C libraries, for both 
performance and security/robustness reasons, and we shouldn't be wasting 
our development resources trying to keep up.


> By "pay" I meant the development, debugging, and maintenance costs,
> not the run-time costs.

I meant both.

> A typical non-trivial Emacs session takes several seconds, sometimes
> 25 or more, to start

?!  That may be typical for *you*. It is not typical for me. On the 
six-year-old desktop at work that I'm using to type this message (hard 
disks, no flash) in normal mode, Emacs by default takes 1.2 seconds to 
start up. Even 1.2 seconds is too long, as I start up Emacs a lot.

> Their
> developers could easily decide that these jobs don't need to be
> supported

That's not likely. C compilers are commonly used as back ends for other 
systems. Compiler writers take that part of the job seriously.

> all you need is to fixup the pointers
> in the dumped data accordingly.  Since the final effect of the
> randomization is just to change the addresses by some fixed amount,
No, every block is put into a random location. Otherwise it's not 
random. So different values need to be added to different pointers. 
Worse, you have to know where the pointers are.

> They develop compilers and linkers, not tools to
> undump Emacs.

And as long as we use them as compilers and linkers, we will be fine. We 
got into the current mess because we went under the covers of the 
underlying systems. That was reasonable in the 1980s when things were 
simpler, but it is not reasonable now.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 09:09:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 09 05:09:59 2016
Received: from localhost ([127.0.0.1]:54197 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1biHot-00028H-4D
	for submit <at> debbugs.gnu.org; Fri, 09 Sep 2016 05:09:59 -0400
Received: from eggs.gnu.org ([208.118.235.92]:44131)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1biHor-000285-8o
 for 23529 <at> debbugs.gnu.org; Fri, 09 Sep 2016 05:09:57 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1biHoh-0007QS-CU
 for 23529 <at> debbugs.gnu.org; Fri, 09 Sep 2016 05:09:51 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42759)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1biHoh-0007QJ-9D; Fri, 09 Sep 2016 05:09:47 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1516
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1biHof-0007Ll-BY; Fri, 09 Sep 2016 05:09:45 -0400
Date: Fri, 09 Sep 2016 12:09:36 +0300
Message-Id: <838tv18mnj.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <c74dafef-53ff-7a6e-d905-2583c1a78451@HIDDEN> (message from
 Paul Eggert on Fri, 9 Sep 2016 01:54:07 -0700)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN> <83eg4vab5o.fsf@HIDDEN>
 <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN> <831t0va8br.fsf@HIDDEN>
 <478e7c97-9339-5072-f9c1-ec67a45113aa@HIDDEN> <83h99p8wbh.fsf@HIDDEN>
 <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@HIDDEN> <83d1kd8qb7.fsf@HIDDEN>
 <c74dafef-53ff-7a6e-d905-2583c1a78451@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -6.3 (------)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.3 (------)

> Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
> From: Paul Eggert <eggert@HIDDEN>
> Date: Fri, 9 Sep 2016 01:54:07 -0700
> 
> Eli Zaretskii wrote:
> 
> > Lisp objects are referenced through the obarray
> 
> Sure, but they are also referenced in many other ways. The obarray is just one 
> corner of this.

Can you elaborate about the other ways you had in mind?

> >> Sure, but that's true of any dumping method.
> >
> > Writing out the dumped data is almost trivial
> 
> Not really. Not nowadays.

Again, please elaborate.

What I had in mind is just a single 'write' (resp. 'read') call for
any contiguous region of memory.  (For best results, we will probably
want to use gmalloc so that it allocates memory off a single array we
define, so that we have fewer regions to write and read.)

> >> The advantage of dumping to C code is that the compiler and linker
> >> will deserialize it for you.
> >
> > That's true, but I think you pay much more in the serialization phase.
> 
> That's fine. Serialization is rare, typically just when Emacs is built. 

By "pay" I meant the development, debugging, and maintenance costs,
not the run-time costs.

> Deserialization is much more common, typically whenever Emacs starts up. So it 
> can be a win to speed up and simplify deserialization at the expense of 
> serialization.

A typical non-trivial Emacs session takes several seconds, sometimes
25 or more, to start, so I don't think the un-dumping that needs to
read the data will be significant.  (Isn't that more or less what
XEmacs did with their "portable dumper"?)

> > the compiler and the linker were not meant for these jobs
> 
> I don't see why today's compilers and linkers wouldn't be up to these jobs. 

They are up to it today, but they are not meant for it.  Their
developers could easily decide that these jobs don't need to be
supported, and then we will be in the same situation as we are today
vis-à-vis the glibc development.

> > writing the dumped data and then reading it with fixups is
> > something we can do ourselves without relying on any external
> > technologies which need to be bent to our needs.
> 
> I don't think so. We need to rely on and/or work around properties of address 
> randomization which will be platform-dependent.

By the time you read the dumped data into Emacs, the randomization
will have been done already, so all you need is to fixup the pointers
in the dumped data accordingly.  Since the final effect of the
randomization is just to change the addresses by some fixed amount,
the fixup should be trivial, once you have a way of finding all the
pointers which need that.

> > As the number of people who are able to futz with Emacs
> > internals at this depth continues to dwindle,
> 
> This is exactly why we should let the compiler- and linker-writers do this work 
> for us.

But they won't!  They develop compilers and linkers, not tools to
undump Emacs.  Our specific use of their tools is not in their
projects' goals.

We once thought that Emacs is important enough for the Free Software
libraries to tweak themselves to accommodate us.  We were proven
wrong.  (AFAIK, only one Free Software library took that seriously,
and does that to this day.)  I see no reason to believe we will never
bump into similar problems by using tools whose main job is something
else.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 08:54:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 09 04:54:16 2016
Received: from localhost ([127.0.0.1]:54188 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1biHZg-0001l8-Ov
	for submit <at> debbugs.gnu.org; Fri, 09 Sep 2016 04:54:16 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:43242)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1biHZf-0001kw-4X
 for 23529 <at> debbugs.gnu.org; Fri, 09 Sep 2016 04:54:15 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5195D161222;
 Fri,  9 Sep 2016 01:54:08 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id Wt7-ViVr5R-d; Fri,  9 Sep 2016 01:54:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 793FC161223;
 Fri,  9 Sep 2016 01:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id 5t3okRExyvRt; Fri,  9 Sep 2016 01:54:07 -0700 (PDT)
Received: from [192.168.1.9] (unknown [100.32.155.148])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 544B1161222;
 Fri,  9 Sep 2016 01:54:07 -0700 (PDT)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Eli Zaretskii <eliz@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN> <83eg4vab5o.fsf@HIDDEN>
 <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN> <831t0va8br.fsf@HIDDEN>
 <478e7c97-9339-5072-f9c1-ec67a45113aa@HIDDEN> <83h99p8wbh.fsf@HIDDEN>
 <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@HIDDEN> <83d1kd8qb7.fsf@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <c74dafef-53ff-7a6e-d905-2583c1a78451@HIDDEN>
Date: Fri, 9 Sep 2016 01:54:07 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <83d1kd8qb7.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.3 (-)

Eli Zaretskii wrote:

> Lisp objects are referenced through the obarray

Sure, but they are also referenced in many other ways. The obarray is jus=
t one=20
corner of this.

>> Sure, but that's true of any dumping method.
>
> Writing out the dumped data is almost trivial

Not really. Not nowadays.

>> The advantage of dumping to C code is that the compiler and linker
>> will deserialize it for you.
>
> That's true, but I think you pay much more in the serialization phase.

That's fine. Serialization is rare, typically just when Emacs is built.=20
Deserialization is much more common, typically whenever Emacs starts up. =
So it=20
can be a win to speed up and simplify deserialization at the expense of=20
serialization.

> the compiler and the linker were not meant for these jobs

I don't see why today's compilers and linkers wouldn't be up to these job=
s.=20
Emacs is not that large by today's standards. The proof of that will be i=
n the=20
pudding, no?

> writing the dumped data and then reading it with fixups is
> something we can do ourselves without relying on any external
> technologies which need to be bent to our needs.

I don't think so. We need to rely on and/or work around properties of add=
ress=20
randomization which will be platform-dependent. It will be tempting to do=
 the=20
job poorly, and lose any reliability and/or security benefits of randomiz=
ation=20
that we might otherwise get for free. Letting the compiler and linker do =
this=20
work for us will save us work in the long run.

> As the number of people who are able to futz with Emacs
> internals at this depth continues to dwindle,

This is exactly why we should let the compiler- and linker-writers do thi=
s work=20
for us.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 07:50:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 09 03:50:58 2016
Received: from localhost ([127.0.0.1]:54158 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1biGaQ-0000Gd-A4
	for submit <at> debbugs.gnu.org; Fri, 09 Sep 2016 03:50:58 -0400
Received: from eggs.gnu.org ([208.118.235.92]:55731)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1biGaO-0000GN-AV
 for 23529 <at> debbugs.gnu.org; Fri, 09 Sep 2016 03:50:56 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1biGaE-0003T2-J1
 for 23529 <at> debbugs.gnu.org; Fri, 09 Sep 2016 03:50:51 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41764)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1biGaE-0003Sy-Fs; Fri, 09 Sep 2016 03:50:46 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4606
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1biGaD-0004dF-Ig; Fri, 09 Sep 2016 03:50:45 -0400
Date: Fri, 09 Sep 2016 10:50:36 +0300
Message-Id: <83d1kd8qb7.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@HIDDEN> (message from
 Paul Eggert on Fri, 9 Sep 2016 00:10:22 -0700)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN> <83eg4vab5o.fsf@HIDDEN>
 <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN> <831t0va8br.fsf@HIDDEN>
 <478e7c97-9339-5072-f9c1-ec67a45113aa@HIDDEN> <83h99p8wbh.fsf@HIDDEN> 
 <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -6.3 (------)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.3 (------)

> Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
> From: Paul Eggert <eggert@HIDDEN>
> Date: Fri, 9 Sep 2016 00:10:22 -0700
> 
> Eli Zaretskii wrote:
> 
> > I guess you mean the 'previous' and 'next' pointers?
> 
> I mean all the pointers in the data. There are more than just 'previous' and 
> 'next'. Most Lisp objects are tagged pointers, and data contains them.

Lisp objects are referenced through the obarray, which will be part of
the dumped data, so fixing that up, as part of walking through all the
structures created by temacs, will take care of this problem.  Once
again, a constant offset will do.

> > your proposed method is required to "serialize" the dumped data as C
> > code.
> 
> Sure, but that's true of any dumping method.

No.  Writing out the dumped data is almost trivial, no changes in the
current implementation are needed beyond just the file I/O itself.

> The advantage of dumping to C code is that the compiler and linker
> will deserialize it for you.

That's true, but I think you pay much more in the serialization phase.

In addition, the compiler and the linker were not meant for these
jobs, and their developers certainly don't take such jobs into
account, so we should expect to bump into unexpected problems.  By
contrast, writing the dumped data and then reading it with fixups is
something we can do ourselves without relying on any external
technologies which need to be bent to our needs.  The latter aspects
may well become a problem, not unlike what we have today, at some
future point.  As the number of people who are able to futz with Emacs
internals at this depth continues to dwindle, I don't think we want to
go through replacing this stuff more than just this once, or even
risking that.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 07:10:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 09 03:10:33 2016
Received: from localhost ([127.0.0.1]:54135 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1biFxJ-0007kZ-2o
	for submit <at> debbugs.gnu.org; Fri, 09 Sep 2016 03:10:33 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:36506)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1biFxG-0007kL-MM
 for 23529 <at> debbugs.gnu.org; Fri, 09 Sep 2016 03:10:31 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id EACB11611DF;
 Fri,  9 Sep 2016 00:10:23 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id 7LJv0Xe25kfc; Fri,  9 Sep 2016 00:10:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id CA1FD161220;
 Fri,  9 Sep 2016 00:10:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id QRPKZhgoHpL5; Fri,  9 Sep 2016 00:10:22 -0700 (PDT)
Received: from [192.168.1.9] (unknown [100.32.155.148])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id A33121611DF;
 Fri,  9 Sep 2016 00:10:22 -0700 (PDT)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Eli Zaretskii <eliz@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN> <83eg4vab5o.fsf@HIDDEN>
 <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN> <831t0va8br.fsf@HIDDEN>
 <478e7c97-9339-5072-f9c1-ec67a45113aa@HIDDEN> <83h99p8wbh.fsf@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@HIDDEN>
Date: Fri, 9 Sep 2016 00:10:22 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <83h99p8wbh.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.3 (-)

Eli Zaretskii wrote:

> I guess you mean the 'previous' and 'next' pointers?

I mean all the pointers in the data. There are more than just 'previous' =
and=20
'next'. Most Lisp objects are tagged pointers, and data contains them.

> Emacs doesn't assume LSB representation when built with wide
> ints.

True, I should have said that the representation is always a pointer plus=
 a=20
constant offset, which is true even with wide ints. (It didn't used to be=
 true,=20
but those days are long gone.)

> your proposed method is required to "serialize" the dumped data as C
> code.

Sure, but that's true of any dumping method. The advantage of dumping to =
C code=20
is that the compiler and linker will deserialize it for you.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 05:41:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 09 01:41:10 2016
Received: from localhost ([127.0.0.1]:54102 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1biEYo-0005dp-NF
	for submit <at> debbugs.gnu.org; Fri, 09 Sep 2016 01:41:10 -0400
Received: from eggs.gnu.org ([208.118.235.92]:58156)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1biEYn-0005db-M0
 for 23529 <at> debbugs.gnu.org; Fri, 09 Sep 2016 01:41:09 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1biEYf-00014I-9O
 for 23529 <at> debbugs.gnu.org; Fri, 09 Sep 2016 01:41:04 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40616)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1biEYf-000149-5n; Fri, 09 Sep 2016 01:41:01 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4299
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1biEYd-0001z7-JE; Fri, 09 Sep 2016 01:40:59 -0400
Date: Fri, 09 Sep 2016 08:40:50 +0300
Message-Id: <83h99p8wbh.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <478e7c97-9339-5072-f9c1-ec67a45113aa@HIDDEN> (message from
 Paul Eggert on Wed, 7 Sep 2016 13:12:27 -0700)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN> <83eg4vab5o.fsf@HIDDEN>
 <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN> <831t0va8br.fsf@HIDDEN>
 <478e7c97-9339-5072-f9c1-ec67a45113aa@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -6.3 (------)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.3 (------)

> Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
> From: Paul Eggert <eggert@HIDDEN>
> Date: Wed, 7 Sep 2016 13:12:27 -0700
> 
> On 09/07/2016 11:11 AM, Eli Zaretskii wrote:
> > Data that has to be dumped and loaded are accessed through pointers
> 
> Sure, but the data contains pointers to other data

I guess you mean the 'previous' and 'next' pointers?  Fixing that is
just a simple job of adding a fixed offset to each such pointer.

> (and perhaps to code? I haven't checked)

defsubr does that, but fixing the address of the function after
loading the dumped data is also very simple: for each defsubr, rewrite
its function pointer.

> > We'd need to plug the compiled data into
> > data structures that support the Lisp interpreter, something which the
> > compiler and linker won't help us.
> 
> Ah, but they can! Because Emacs now assumes the LSB representation, 
> Emacs objects now encapsulate pointers simply by adding a constant to 
> them. All C compilers and linkers support that, even for addresses 
> defined by other compilation units.

First, Emacs doesn't assume LSB representation when built with wide
ints.  And second, I think you forget the part of the task that with
your proposed method is required to "serialize" the dumped data as C
code.  AFAIU, you are talking about writing and debugging an entirely
new back-end to all the DEFSYM, DEFVAR, defsubr, etc. stuff we use
during dumping, and in addition some new code that would either
replace lisp_malloc and friends during dumping, to produce C code, or
something that would traverse the Lisp data as part of the new
implementation of unexec and convert the Lisp data into C code.  That
is a formidable job in itself, which I think is much more complex than
data I/O and the necessary fixups.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 7 Sep 2016 20:12:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 07 16:12:40 2016
Received: from localhost ([127.0.0.1]:52918 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhjD6-0001QC-I5
	for submit <at> debbugs.gnu.org; Wed, 07 Sep 2016 16:12:40 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:46104)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1bhjD4-0001Py-8R
 for 23529 <at> debbugs.gnu.org; Wed, 07 Sep 2016 16:12:38 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 78B82161171;
 Wed,  7 Sep 2016 13:12:31 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id RwkXOE1XCNWW; Wed,  7 Sep 2016 13:12:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id BFE80161149;
 Wed,  7 Sep 2016 13:12:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id KQi6QT7VAR5v; Wed,  7 Sep 2016 13:12:30 -0700 (PDT)
Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id A4A55161144;
 Wed,  7 Sep 2016 13:12:30 -0700 (PDT)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Eli Zaretskii <eliz@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN> <83eg4vab5o.fsf@HIDDEN>
 <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN> <831t0va8br.fsf@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <478e7c97-9339-5072-f9c1-ec67a45113aa@HIDDEN>
Date: Wed, 7 Sep 2016 13:12:27 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <831t0va8br.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.1 (-)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.1 (-)

On 09/07/2016 11:11 AM, Eli Zaretskii wrote:
> Data that has to be dumped and loaded are accessed through pointers

Sure, but the data contains pointers to other data (and perhaps to code? 
I haven't checked), and when the pointer-containing data is loaded into 
a fresh Emacs those pointers need to be relocated appropriately for the 
new Emacs.

> We'd need to plug the compiled data into
> data structures that support the Lisp interpreter, something which the
> compiler and linker won't help us.

Ah, but they can! Because Emacs now assumes the LSB representation, 
Emacs objects now encapsulate pointers simply by adding a constant to 
them. All C compilers and linkers support that, even for addresses 
defined by other compilation units.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 7 Sep 2016 18:12:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 07 14:12:00 2016
Received: from localhost ([127.0.0.1]:52872 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhhKK-0006yL-92
	for submit <at> debbugs.gnu.org; Wed, 07 Sep 2016 14:12:00 -0400
Received: from eggs.gnu.org ([208.118.235.92]:39224)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1bhhKI-0006y6-I6
 for 23529 <at> debbugs.gnu.org; Wed, 07 Sep 2016 14:11:59 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1bhhKA-0004vy-7K
 for 23529 <at> debbugs.gnu.org; Wed, 07 Sep 2016 14:11:53 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45743)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1bhhKA-0004vq-3x; Wed, 07 Sep 2016 14:11:50 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2352
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1bhhK8-0000TI-6a; Wed, 07 Sep 2016 14:11:48 -0400
Date: Wed, 07 Sep 2016 21:11:36 +0300
Message-Id: <831t0va8br.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN> (message from
 Paul Eggert on Wed, 7 Sep 2016 10:40:14 -0700)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN> <83eg4vab5o.fsf@HIDDEN>
 <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -6.1 (------)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.1 (------)

> Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
> From: Paul Eggert <eggert@HIDDEN>
> Date: Wed, 7 Sep 2016 10:40:14 -0700
> 
> Eli Zaretskii wrote:
> >> PIE can relocate data as well as code.
> > Since we will be reading data into existing variables, that would
> > happen automatically.
> 
> I'm afraid I'm not following. Any existing variables (i.e., existing in Emacs 
> when it starts up) are of fixed size, so they can't hold all the data of a 
> dumped Emacs. The newly starting-up Emacs must decide how much storage to 
> allocate to hold the dumped state that Emacs is about to read.  This storage's 
> addresses should be randomized, and the data that Emacs reads will contain 
> pointers-to-data that Emacs itself would need to relocate.

Data that has to be dumped and loaded are accessed through pointers
(since it's malloced in temacs).  When Emacs starts, it will allocate
memory off the heap and read the dumped data into that, using those
pointers to access it.  The pointers are of fixed size, so they will
already exist in the Emacs binary (and relocated if PIE wants that).
I assume that randomization affects the addresses of the buffers
allocated off the heap, so we don't need to do anything else to
randomize the data we load.

> All this is doable, of course. It's just that it should be easier and more 
> portable to use the existing compilers and linkers rather than reinvent the wheel.

I very much doubt that it would be easier, since linking nowadays is
also much more complicated.  We'd need to plug the compiled data into
data structures that support the Lisp interpreter, something which the
compiler and linker won't help us.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 7 Sep 2016 17:40:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 07 13:40:23 2016
Received: from localhost ([127.0.0.1]:52861 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhgpj-0006D5-9F
	for submit <at> debbugs.gnu.org; Wed, 07 Sep 2016 13:40:23 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:52184)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1bhgph-0006Cp-8X
 for 23529 <at> debbugs.gnu.org; Wed, 07 Sep 2016 13:40:21 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6D163160195;
 Wed,  7 Sep 2016 10:40:15 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id EHNeilhLq97G; Wed,  7 Sep 2016 10:40:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id B6A6516111A;
 Wed,  7 Sep 2016 10:40:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id ekmFlHvRZY8j; Wed,  7 Sep 2016 10:40:14 -0700 (PDT)
Received: from [192.168.1.9] (unknown [100.32.155.148])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 947C4160195;
 Wed,  7 Sep 2016 10:40:14 -0700 (PDT)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Eli Zaretskii <eliz@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN> <83eg4vab5o.fsf@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <a0c4112f-aaad-29d2-6f23-a40b9ff76454@HIDDEN>
Date: Wed, 7 Sep 2016 10:40:14 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <83eg4vab5o.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.1 (-)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.1 (-)

Eli Zaretskii wrote:
>> PIE can relocate data as well as code.
> Since we will be reading data into existing variables, that would
> happen automatically.

I'm afraid I'm not following. Any existing variables (i.e., existing in E=
macs=20
when it starts up) are of fixed size, so they can't hold all the data of =
a=20
dumped Emacs. The newly starting-up Emacs must decide how much storage to=
=20
allocate to hold the dumped state that Emacs is about to read.  This stor=
age's=20
addresses should be randomized, and the data that Emacs reads will contai=
n=20
pointers-to-data that Emacs itself would need to relocate.

All this is doable, of course. It's just that it should be easier and mor=
e=20
portable to use the existing compilers and linkers rather than reinvent t=
he wheel.

>> > And with modules, we also have code to dump.
> ??? What do you mean by that?  Modules cannot be preloaded, AFAIK.

You're right, saving objects as C source code doesn't fix that problem al=
l by=20
itself.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 7 Sep 2016 17:11:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 07 13:11:09 2016
Received: from localhost ([127.0.0.1]:52852 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhgNR-0005Wf-IQ
	for submit <at> debbugs.gnu.org; Wed, 07 Sep 2016 13:11:09 -0400
Received: from eggs.gnu.org ([208.118.235.92]:53241)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1bhgNP-0005WH-DX
 for 23529 <at> debbugs.gnu.org; Wed, 07 Sep 2016 13:11:08 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1bhgNH-0001Qi-3W
 for 23529 <at> debbugs.gnu.org; Wed, 07 Sep 2016 13:11:02 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45058)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1bhgNH-0001QZ-0B; Wed, 07 Sep 2016 13:10:59 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2195
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1bhgND-00084m-1G; Wed, 07 Sep 2016 13:10:57 -0400
Date: Wed, 07 Sep 2016 20:10:27 +0300
Message-Id: <83eg4vab5o.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN> (message from
 Paul Eggert on Wed, 7 Sep 2016 09:11:31 -0700)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> <83r38vaiyh.fsf@HIDDEN>
 <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -6.1 (------)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.1 (------)

> Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
> From: Paul Eggert <eggert@HIDDEN>
> Date: Wed, 7 Sep 2016 09:11:31 -0700
> 
> >> Another example: on hardened platforms with PIEs
> >> (position-independent executables), you get a PIE for free as the
> >> dumped executable, instead of having to disable PIE as we do now.
> >
> > I'm not sure how PIE is relevant: the stuff we dump, and need to load
> > into a running Emacs, is data, not code.  What am I missing?
> 
> PIE can relocate data as well as code.

Since we will be reading data into existing variables, that would
happen automatically.

> And with modules, we also have code to dump.

??? What do you mean by that?  Modules cannot be preloaded, AFAIK.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 7 Sep 2016 16:11:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 07 12:11:44 2016
Received: from localhost ([127.0.0.1]:52833 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhfRw-00044Y-55
	for submit <at> debbugs.gnu.org; Wed, 07 Sep 2016 12:11:44 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:35384)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1bhfRu-00044M-HT
 for 23529 <at> debbugs.gnu.org; Wed, 07 Sep 2016 12:11:43 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id D2FE7161168;
 Wed,  7 Sep 2016 09:11:35 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id aUgH55u05-G2; Wed,  7 Sep 2016 09:11:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2A22F161173;
 Wed,  7 Sep 2016 09:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id OmTmUQN5zyxe; Wed,  7 Sep 2016 09:11:35 -0700 (PDT)
Received: from [192.168.1.9] (unknown [100.32.155.148])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 068D1161168;
 Wed,  7 Sep 2016 09:11:35 -0700 (PDT)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Eli Zaretskii <eliz@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> <83r38vaiyh.fsf@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <c68db569-e5d8-0910-b86f-040f268d4f58@HIDDEN>
Date: Wed, 7 Sep 2016 09:11:31 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <83r38vaiyh.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.1 (-)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.1 (-)

Eli Zaretskii wrote:

>> The compiler-based approach should be simpler and more portable than
>> messing with low-level binary I/O.
>
> You mean, 'read' and 'write'?

I meant all the other stuff associated with the I/O.

>> Another example: on hardened platforms with PIEs
>> (position-independent executables), you get a PIE for free as the
>> dumped executable, instead of having to disable PIE as we do now.
>
> I'm not sure how PIE is relevant: the stuff we dump, and need to load
> into a running Emacs, is data, not code.  What am I missing?

PIE can relocate data as well as code. And with modules, we also have code to dump.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 7 Sep 2016 14:22:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 07 10:22:26 2016
Received: from localhost ([127.0.0.1]:52762 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhdk9-0006gl-T6
	for submit <at> debbugs.gnu.org; Wed, 07 Sep 2016 10:22:26 -0400
Received: from eggs.gnu.org ([208.118.235.92]:40148)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1bhdk5-0006gR-Tl
 for 23529 <at> debbugs.gnu.org; Wed, 07 Sep 2016 10:22:24 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1bhdjx-0000KY-6y
 for 23529 <at> debbugs.gnu.org; Wed, 07 Sep 2016 10:22:16 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42870)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1bhdjx-0000KU-3H; Wed, 07 Sep 2016 10:22:13 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1744
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1bhdjv-0006H2-50; Wed, 07 Sep 2016 10:22:11 -0400
Date: Wed, 07 Sep 2016 17:21:58 +0300
Message-Id: <83r38vaiyh.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN> (message from
 Paul Eggert on Tue, 6 Sep 2016 13:37:20 -0700)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -6.1 (------)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.1 (------)

> Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
> From: Paul Eggert <eggert@HIDDEN>
> Date: Tue, 6 Sep 2016 13:37:20 -0700
> 
> On 09/06/2016 12:18 PM, Eli Zaretskii wrote:
> > Then users on those platforms will never be able to re-dump.
> 
> True. But they'll still be better off than they are now, since they 
> can't dump at all now. Plus, for extra credit we could dynamically link 
> the dumped object modules at Emacs startup, with the idea of making it 
> practical to re-dump.

That would be good, thanks.  I still think we should consider
approaches that don't require a compiler.

> The compiler-based approach should be simpler and more portable than 
> messing with low-level binary I/O.

You mean, 'read' and 'write'?  That's hardly problematic, and is
available on all supported platforms.  Even 'mmap' is reasonably
portable.

> Another example: on hardened platforms with PIEs
> (position-independent executables), you get a PIE for free as the
> dumped executable, instead of having to disable PIE as we do now.

I'm not sure how PIE is relevant: the stuff we dump, and need to load
into a running Emacs, is data, not code.  What am I missing?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 7 Sep 2016 11:02:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 07 07:02:11 2016
Received: from localhost ([127.0.0.1]:51941 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhacM-00005y-QO
	for submit <at> debbugs.gnu.org; Wed, 07 Sep 2016 07:02:10 -0400
Received: from mail-wm0-f43.google.com ([74.125.82.43]:35299)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1bhacK-00005m-QM
 for 23529 <at> debbugs.gnu.org; Wed, 07 Sep 2016 07:02:09 -0400
Received: by mail-wm0-f43.google.com with SMTP id i204so79735479wma.0
 for <23529 <at> debbugs.gnu.org>; Wed, 07 Sep 2016 04:02:08 -0700 (PDT)
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; bh=6cRf3XtTx77lT17PLLFSDhwqElp8krw0siHzB5yyCl4=;
 b=KHcCnlpOrUn8TVwO+D4EqceiS79RuMKuvpq5F24tr3jftOKBYfDkLoP3oUhd9+1znb
 LPg7LddLn0CVtoxucMxS+n0JfEyVWlQNUWGr/CI6FqJUaOphjF88wUlB0BXkCqgrHKQ9
 7eF9hQxmGjx9zITzdbagRNAuXz0CaA2s0pKvpV06vYgPMHf1hev24E3ImuL30WlqSh3A
 hFsKBOSsjJ+550abAptu+1SC0Np3aLjhlgFLbzpYxiHQmxCwq/419hncbasMJ5rBZlRG
 kVcqaJKChtbRhqIwu5uDPICZhL8epK1+3rgA82fib/gRbA9lrmLqJCzNL8Idlg8Ab3ku
 /6tQ==
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;
 bh=6cRf3XtTx77lT17PLLFSDhwqElp8krw0siHzB5yyCl4=;
 b=gL4RiZJg8wc2TghDcU5TbkJ1m08d+Qy8YA8KP3SQEpbyuaqv5yy3TRCVBJY78ryAME
 jJS9qGh8HpaAxE3/xal3cp28oFZZdJEoIwTxeJnneUt+GzPUYx4KnhlvZajGcLmrFYG7
 BMjq1j0XOT6N/pJ/upOfMl6F99OgWehswzNfHX5E0943jqkvaPH9YT0rPchBcqRZgllG
 drcJJMFajLbXvq5OkEkTifkRmYbp5o+HtJvI+lmoWXh7N6YYliaIuFgv7bLKtoX1U0AZ
 DwnKEuk1hs7F23N6mnCkFMyZbAG4z8Egp0FEdlhY+FFCqEJfvF8CR4HIwiIcxhAJ2PIu
 FWcg==
X-Gm-Message-State: AE9vXwOyGjSWMmss5m+gutfALiIZJKqTZEHUXoGFMxrvlGmv6rgmMhwIRs6KDCV7GcjvW7diXz5GGbDX/iwoQw==
X-Received: by 10.28.232.71 with SMTP id f68mr3382964wmh.55.1473246122975;
 Wed, 07 Sep 2016 04:02:02 -0700 (PDT)
MIME-Version: 1.0
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN>
 <CAGK7Mr4nDYEEwEY=1hkGoWNA1Db_PdAqP25NgkRPDH4J2jV8pw@HIDDEN>
 <1a792452-b263-48a8-0adc-0b984315649e@HIDDEN>
In-Reply-To: <1a792452-b263-48a8-0adc-0b984315649e@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Wed, 07 Sep 2016 11:01:52 +0000
Message-ID: <CAArVCkRPwQr+ds0_LZsKK_g0WVWChEXYeTnGT=e-tRWY0T3Nfg@HIDDEN>
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Paul Eggert <eggert@HIDDEN>,
 Philippe Vaucher <philippe.vaucher@HIDDEN>
Content-Type: multipart/alternative; boundary=001a1146a152d3a78f053be8d7df
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Paul Eggert schrieb am Mi.,
 7. Sep. 2016 um 09:40 Uhr: > Philippe
 Vaucher wrote: > > Would that also avoid having to require special privileges
 when building? > > e.g the "personality" syscall. > > I hope not. > [...]
 Content analysis details:   (1.9 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 2.4 RCVD_IN_SORBS_SPAM     RBL: SORBS: sender is a spam source
 [74.125.82.43 listed in dnsbl.sorbs.net]
 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
 (p.stephani2[at]gmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
 digit (p.stephani2[at]gmail.com)
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at http://www.dnswl.org/, low
 trust [74.125.82.43 listed in list.dnswl.org]
 0.0 HTML_MESSAGE           BODY: HTML included in message
 -0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
 [74.125.82.43 listed in wl.mailspike.net]
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid
X-Debbugs-Envelope-To: 23529
Cc: Eli Zaretskii <eliz@HIDDEN>, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Paul Eggert schrieb am Mi., 7. Sep. 2016 um 09:40 Uhr: > Philippe
    Vaucher wrote: > > Would that also avoid having to require special privileges
    when building? > > e.g the "personality" syscall. > > I hope not. > [...]
    
 
 Content analysis details:   (1.9 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at http://www.dnswl.org/, low
                             trust
                             [74.125.82.43 listed in list.dnswl.org]
  2.4 RCVD_IN_SORBS_SPAM     RBL: SORBS: sender is a spam source
                             [74.125.82.43 listed in dnsbl.sorbs.net]
 -0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
                             [74.125.82.43 listed in wl.mailspike.net]
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail provider
                             (p.stephani2[at]gmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
                             digit (p.stephani2[at]gmail.com)
  0.0 HTML_MESSAGE           BODY: HTML included in message
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
  0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid

--001a1146a152d3a78f053be8d7df
Content-Type: text/plain; charset=UTF-8

Paul Eggert <eggert@HIDDEN> schrieb am Mi., 7. Sep. 2016 um 09:40 Uhr:

> Philippe Vaucher wrote:
> > Would that also avoid having to require special privileges when building?
> > e.g the "personality" syscall.
>
> I hope not.
>

I hope you mean "I hope so" :)
I think any new dumper should be portable enough to work with ASLR, ASan,
... (essentially just portable C code).

--001a1146a152d3a78f053be8d7df
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">Paul E=
ggert &lt;<a href=3D"mailto:eggert@HIDDEN">eggert@HIDDEN</a>&gt; =
schrieb am Mi., 7. Sep. 2016 um 09:40=C2=A0Uhr:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">Philippe Vaucher wrote:<br class=3D"gmail_msg">
&gt; Would that also avoid having to require special privileges when buildi=
ng?<br class=3D"gmail_msg">
&gt; e.g the &quot;personality&quot; syscall.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
I hope not.<br class=3D"gmail_msg"></blockquote><div><br></div><div>I hope =
you mean &quot;I hope so&quot; :)</div><div>I think any new dumper should b=
e portable enough to work with ASLR, ASan, ... (essentially just portable C=
 code).=C2=A0</div></div></div>

--001a1146a152d3a78f053be8d7df--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 7 Sep 2016 07:40:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 07 03:40:34 2016
Received: from localhost ([127.0.0.1]:51885 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhXTG-0003cZ-BZ
	for submit <at> debbugs.gnu.org; Wed, 07 Sep 2016 03:40:34 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:39574)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1bhXTF-0003cM-Be
 for 23529 <at> debbugs.gnu.org; Wed, 07 Sep 2016 03:40:33 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 86B27160DFF;
 Wed,  7 Sep 2016 00:40:26 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id wQkEb3xm7t8P; Wed,  7 Sep 2016 00:40:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6D11D161121;
 Wed,  7 Sep 2016 00:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id f78ejz-KprVG; Wed,  7 Sep 2016 00:40:25 -0700 (PDT)
Received: from [192.168.1.9] (unknown [100.32.155.148])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 1E7D8160D74;
 Wed,  7 Sep 2016 00:40:25 -0700 (PDT)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Philippe Vaucher <philippe.vaucher@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN>
 <CAGK7Mr4nDYEEwEY=1hkGoWNA1Db_PdAqP25NgkRPDH4J2jV8pw@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <1a792452-b263-48a8-0adc-0b984315649e@HIDDEN>
Date: Wed, 7 Sep 2016 00:40:22 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAGK7Mr4nDYEEwEY=1hkGoWNA1Db_PdAqP25NgkRPDH4J2jV8pw@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.1 (-)
X-Debbugs-Envelope-To: 23529
Cc: Eli Zaretskii <eliz@HIDDEN>, p.stephani2@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.1 (-)

Philippe Vaucher wrote:
> Would that also avoid having to require special privileges when building?
> e.g the "personality" syscall.

I hope not.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 7 Sep 2016 07:13:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 07 03:13:02 2016
Received: from localhost ([127.0.0.1]:51868 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhX2b-0002y7-RG
	for submit <at> debbugs.gnu.org; Wed, 07 Sep 2016 03:13:01 -0400
Received: from mail-vk0-f54.google.com ([209.85.213.54]:33885)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philippe.vaucher@HIDDEN>) id 1bhX2a-0002xm-Fi
 for 23529 <at> debbugs.gnu.org; Wed, 07 Sep 2016 03:13:00 -0400
Received: by mail-vk0-f54.google.com with SMTP id v189so5786758vkv.1
 for <23529 <at> debbugs.gnu.org>; Wed, 07 Sep 2016 00:13:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to
 :cc; bh=lpo6PFlMoWQA5PPfRUq2xPvtBrlE0LtJv+XRDgOw8Sw=;
 b=Am27/up7VeY4MNlojW8Wi0pDeNnvfXxAX7j+Zs1GRGIBrxWWo6D0+Q4+fPWNZ6m3Ip
 GLR/Qe8zhbwm/7+0dDW9SdxFoFlJDmzufYy+2eS0Q0xHsF4re55N25DrlKuoBmnqxp+E
 6JCZtA46E2amhERGv2I9FK/5eCyA1L+uKUpAbzYlRhfPPBiRUFCphwPx7SQazKqJovP0
 qjqV+j+5/T1BWz8WNJTElwWNvGKa6ZsQrIjc7pkNOePeoPHTw3g0vmPMokyiqu3lomgV
 WC+ydCAXhCbcI1+cAgcAuInFSfbonHP7SfpGuVpIfqW/TL01b9mK43D91M/m/K/7VNJ4
 +Xjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:in-reply-to:references:from:date
 :message-id:subject:to:cc;
 bh=lpo6PFlMoWQA5PPfRUq2xPvtBrlE0LtJv+XRDgOw8Sw=;
 b=K6b+k+WvM8dJ/qck9c5TulgE7LRndlP/eggG9cJSRTMbSKgC6M77FddFSzOvuG7hNE
 lEvRaWj4y+vDj6ccEmt8h1ifHFW4wx9uHTx2UHKmzQmMkrfwg28IAdSNMepM1RypRlpA
 dO3Qu2zv35xRry4gz75HwOQhi2r4kBrR/iouATTMrWrzts2bfZDuGdZzfRQBbAMSqerU
 bjHiqZ2isfkuv4KvInV5J3GBEekUH5ycWZKgKOHEh00wLOqZnCO3n2/yHgHLdfuxhb9B
 Ta5ScCufdzrAbv/B+D/OkygwQk6DFchcE+NwKWDGKgU3flL6cX7UXv/wnV5FYYD47Jz5
 AFvw==
X-Gm-Message-State: AE9vXwMi+agvQgbO3FkYE6WAIgbf0qnccjouOzq+660qFzyPNQ7lbw6DkVOuQc92uo8mUF2l0rXZOmqZDPAZ2Q==
X-Received: by 10.31.3.135 with SMTP id f7mr16579579vki.20.1473232375072; Wed,
 07 Sep 2016 00:12:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.44.18 with HTTP; Wed, 7 Sep 2016 00:12:24 -0700 (PDT)
In-Reply-To: <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
 <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN>
From: Philippe Vaucher <philippe.vaucher@HIDDEN>
Date: Wed, 7 Sep 2016 09:12:24 +0200
Message-ID: <CAGK7Mr4nDYEEwEY=1hkGoWNA1Db_PdAqP25NgkRPDH4J2jV8pw@HIDDEN>
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Paul Eggert <eggert@HIDDEN>
Content-Type: multipart/alternative; boundary=001a11427d1a635203053be5a446
X-Spam-Score: 1.7 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  > > Although Emacs can do this sort of work itself (e.g.,
 randomizing > locations of dumped objects, munging pointers as they come in
 to match the > random locations, and using mmap to make the relevant objects
 const), it > should be better for Emacs to use the linking technology already
 available > on modern platforms, rather than trying to reinvent the wheel.
 > [...] Content analysis details:   (1.7 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
 (philippe.vaucher[at]gmail.com)
 2.4 RCVD_IN_SORBS_SPAM     RBL: SORBS: sender is a spam source
 [209.85.213.54 listed in dnsbl.sorbs.net]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at http://www.dnswl.org/, low
 trust [209.85.213.54 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
 [209.85.213.54 listed in wl.mailspike.net]
 0.0 HTML_MESSAGE           BODY: HTML included in message
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid
X-Debbugs-Envelope-To: 23529
Cc: Eli Zaretskii <eliz@HIDDEN>, p.stephani2@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.7 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  > > Although Emacs can do this sort of work itself (e.g.,
   randomizing > locations of dumped objects, munging pointers as they come in
    to match the > random locations, and using mmap to make the relevant objects
    const), it > should be better for Emacs to use the linking technology already
    available > on modern platforms, rather than trying to reinvent the wheel.
    > [...] 
 
 Content analysis details:   (1.7 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at http://www.dnswl.org/, low
                             trust
                             [209.85.213.54 listed in list.dnswl.org]
  2.4 RCVD_IN_SORBS_SPAM     RBL: SORBS: sender is a spam source
                             [209.85.213.54 listed in dnsbl.sorbs.net]
 -0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
                             [209.85.213.54 listed in wl.mailspike.net]
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail provider
                             (philippe.vaucher[at]gmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 HTML_MESSAGE           BODY: HTML included in message
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
  0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid

--001a11427d1a635203053be5a446
Content-Type: text/plain; charset=UTF-8

>
> Although Emacs can do this sort of work itself (e.g., randomizing
> locations of dumped objects, munging pointers as they come in to match the
> random locations, and using mmap to make the relevant objects const), it
> should be better for Emacs to use the linking technology already available
> on modern platforms, rather than trying to reinvent the wheel.
>

I agree.

Would that also avoid having to require special privileges when building?
e.g the "personality" syscall.

Philippe

--001a11427d1a635203053be5a446
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);paddi=
ng-left:1ex">Although Emacs can do this sort of work itself (e.g., randomiz=
ing locations of dumped objects, munging pointers as they come in to match =
the random locations, and using mmap to make the relevant objects const), i=
t should be better for Emacs to use the linking technology already availabl=
e on modern platforms, rather than trying to reinvent the wheel.<br></block=
quote><div><br></div><div>I agree.</div><div><br></div><div>Would that also=
 avoid having to require special privileges when building? e.g the &quot;pe=
rsonality&quot; syscall.<br></div><div><br></div><div>Philippe=C2=A0</div><=
/div></div></div>

--001a11427d1a635203053be5a446--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 20:38:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 06 16:38:56 2016
Received: from localhost ([127.0.0.1]:51750 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhN8j-0002qi-Q4
	for submit <at> debbugs.gnu.org; Tue, 06 Sep 2016 16:38:56 -0400
Received: from [131.179.128.68] (port=36934 helo=zimbra.cs.ucla.edu)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1bhN8S-0002ot-VX
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 16:38:40 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6F71E160195;
 Tue,  6 Sep 2016 13:37:22 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id eElLLRBj-7RZ; Tue,  6 Sep 2016 13:37:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id A3950160DFF;
 Tue,  6 Sep 2016 13:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id JrF7xIAHZ4Fq; Tue,  6 Sep 2016 13:37:21 -0700 (PDT)
Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 87B6C160195;
 Tue,  6 Sep 2016 13:37:21 -0700 (PDT)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Eli Zaretskii <eliz@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> <83twdsalbk.fsf@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <d52cfb32-0143-95c2-8bff-d097f0b8a2e8@HIDDEN>
Date: Tue, 6 Sep 2016 13:37:20 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <83twdsalbk.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  On 09/06/2016 12:18 PM, Eli Zaretskii wrote: > Then users
 on those platforms will never be able to re-dump. True. But they'll still
 be better off than they are now, since they can't dump at all now. Plus, for
 extra credit we could dynamically link the dumped object modules at Emacs
 startup, with the idea of making it practical to re-dump. [...] 
 Content analysis details:   (1.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  On 09/06/2016 12:18 PM, Eli Zaretskii wrote: > Then users
   on those platforms will never be able to re-dump. True. But they'll still
   be better off than they are now, since they can't dump at all now. Plus, for
    extra credit we could dynamically link the dumped object modules at Emacs
    startup, with the idea of making it practical to re-dump. [...] 
 
 Content analysis details:   (1.3 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  1.3 RDNS_NONE              Delivered to internal network by a host with no rDNS

On 09/06/2016 12:18 PM, Eli Zaretskii wrote:
> Then users on those platforms will never be able to re-dump.

True. But they'll still be better off than they are now, since they 
can't dump at all now. Plus, for extra credit we could dynamically link 
the dumped object modules at Emacs startup, with the idea of making it 
practical to re-dump.

> I actually don't understand why the data should be serialized as C
> code.  Why not just data that is read into memory (with conversion to
> the native format)?  A compiler is not the only way to convert text
> into binary data.

The compiler-based approach should be simpler and more portable than 
messing with low-level binary I/O. For example, it should be easy to 
arrange for some of the objects to be read-only: just declare them to be 
'const'. Another example: on hardened platforms with PIEs 
(position-independent executables), you get a PIE for free as the dumped 
executable, instead of having to disable PIE as we do now.

Although Emacs can do this sort of work itself (e.g., randomizing 
locations of dumped objects, munging pointers as they come in to match 
the random locations, and using mmap to make the relevant objects 
const), it should be better for Emacs to use the linking technology 
already available on modern platforms, rather than trying to reinvent 
the wheel.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 20:01:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 06 16:01:14 2016
Received: from localhost ([127.0.0.1]:51747 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhMYE-0001yV-So
	for submit <at> debbugs.gnu.org; Tue, 06 Sep 2016 16:01:13 -0400
Received: from [212.227.126.131] (port=59135 helo=mout.kundenserver.de)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <clement.pit@HIDDEN>) id 1bhMXy-0001vT-30
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 16:00:57 -0400
Received: from [18.26.2.123] ([18.26.2.123]) by mrelayeu.kundenserver.de
 (mreue002) with ESMTPSA (Nemesis) id 0MRwxl-1bW8GI0t6P-00StQf; Tue, 06 Sep
 2016 21:59:39 +0200
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Eli Zaretskii <eliz@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <07d39d22-0ab8-90c6-e20c-f70d29aa4809@HIDDEN> <83wpioalr3.fsf@HIDDEN>
From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= <clement.pit@HIDDEN>
Message-ID: <0dc33671-4b05-7512-4790-a066b59faf55@HIDDEN>
Date: Tue, 6 Sep 2016 15:59:30 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <83wpioalr3.fsf@HIDDEN>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="Ix6d17jXXHEeW94fNeqcRdCqdtHo7RNp1"
X-Provags-ID: V03:K0:pGFl3wXLhGyS4j5rsnxjRwcXqYlAn+9qWLnZy7a6O8+KeQ/blA+
 4EflRuknQXiOj81/K262ZFffQ3miNoIIZHO/LwsQ/gF1FZeQSZUJa9ULQ9eiUkcZ6QwCeXN
 DsnrvpXll3Om15arA8heDxb0f6uJ2pk54mglnCYmCebkLbdEj6Dejc4nWjFAQ6FXr6TN6vy
 9vf0DfXTfIuZ251piS8Qw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:WqCZ7Cn0J0c=:K4rIIkTw9BtFJxcZsToH0r
 LJLu6ULfkhs0rvhSgu/0GfP1xbK9gIMsqIKalYEJ/Y/fTre8O1CjeAQ1Xgc354KuFYzJnvs8T
 QRCwJQobBoRcAJo5lu6zXK1urqc9EovYX01mAnfaI83X8vtQjxoSPZuU6D4ncAb3/m/9SPlzc
 kjUCKr9iJ0Kw2xMvv/thj8D/Z2uvfTOt0wax4dTdTSGM/pxs5vIiZQJ5WU5ClQHDCPJqadAqQ
 NSpeUgwMAzrrXBSE5/QlbFMIF+IK9wjojXgyFdNXnEeypdxxeIkhfCOf5nz2mErudKvgtONmX
 J2QAIMnR43BE+GSOrV/gbwBhY0pu2Ne7A3Ek3iqjNp5ichdxFo6en3vS8usCYtOCWsvhBVPB6
 /d6R0RKQWXT6eVABVfIGkua0I3cdiTNbhGJqtRW3GRANTe3AYWQSGBTU0I0KeztTDo/cBlm8G
 hntQu0BaS9ZAOCU13DevwDS4IAutvc+7syZ+DLVe+J5I6CbvEozRtbc/TiKGkxuHGE2CrGeno
 Oaz4u3KFAE4vjgZxVOnrhTIMoYdjjPLeuNU12lG4t0bsTcpWuGvnkbw84VUJ4NbwrwhOO3zA/
 F1nabhZVag4m6+9O8Ri1jYHBgAurJ/sxxx68fHsLcBBpeXMdr9vVL4bGQ+PGgNgJOQH4cYEgG
 zLZi+IHppl1qKXr3JU7pM4SbdNWAKON3RWHrSUrtpg+wpb8HClQjr1BET+E/cq/XFqiY=
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  On 2016-09-06 15:09, Eli Zaretskii wrote: >> From: Clément
    Pit--Claudel >> Date: Tue, 6 Sep 2016 14:18:38 -0400 >> >>> So we will be
    giving up the ability of end-users to re-dump their >>> Emacs, unless they
    have a compiler/binutils installed that are >>> compatible with the ones
   used to build the Emacs binary? >> >> Does this feature exist? I keep seeing
    complaints about the fact that it was disabled: > > AFAIR it was disabled
    because no one cared to fix its quirks wrt ASLR > etc. (or maybe some similar
    nuisance). Once the dumped data is > portable, those issues will be all but
    gone. > > Moving to compiled C code will kill that feature for good. [...]
    
 
 Content analysis details:   (1.3 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail provider
                             (clement.pit[at]gmail.com)
  1.3 RDNS_NONE              Delivered to internal network by a host with no rDNS
X-Debbugs-Envelope-To: 23529
Cc: 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  On 2016-09-06 15:09, Eli Zaretskii wrote: >> From: Clément
    Pit--Claudel >> Date: Tue, 6 Sep 2016 14:18:38 -0400 >> >>> So we will be
    giving up the ability of end-users to re-dump their >>> Emacs, unless they
    have a compiler/binutils installed that are >>> compatible with the ones
   used to build the Emacs binary? >> >> Does this feature exist? I keep seeing
    complaints about the fact that it was disabled: > > AFAIR it was disabled
    because no one cared to fix its quirks wrt ASLR > etc. (or maybe some similar
    nuisance). Once the dumped data is > portable, those issues will be all but
    gone. > > Moving to compiled C code will kill that feature for good. [...]
    
 
 Content analysis details:   (1.3 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail provider
                             (clement.pit[at]gmail.com)
  1.3 RDNS_NONE              Delivered to internal network by a host with no rDNS

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Ix6d17jXXHEeW94fNeqcRdCqdtHo7RNp1
Content-Type: multipart/mixed; boundary="f7Vc96GcbjIC1F8lUCa3lMJG9tJbXIIM9";
 protected-headers="v1"
From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= <clement.pit@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 23529 <at> debbugs.gnu.org
Message-ID: <0dc33671-4b05-7512-4790-a066b59faf55@HIDDEN>
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <07d39d22-0ab8-90c6-e20c-f70d29aa4809@HIDDEN> <83wpioalr3.fsf@HIDDEN>
In-Reply-To: <83wpioalr3.fsf@HIDDEN>

--f7Vc96GcbjIC1F8lUCa3lMJG9tJbXIIM9
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 2016-09-06 15:09, Eli Zaretskii wrote:
>> From: Cl=E9ment Pit--Claudel <clement.pit@HIDDEN>
>> Date: Tue, 6 Sep 2016 14:18:38 -0400
>>
>>> So we will be giving up the ability of end-users to re-dump their
>>> Emacs, unless they have a compiler/binutils installed that are
>>> compatible with the ones used to build the Emacs binary?
>>
>> Does this feature exist? I keep seeing complaints about the fact that =
it was disabled:
>=20
> AFAIR it was disabled because no one cared to fix its quirks wrt ASLR
> etc. (or maybe some similar nuisance).  Once the dumped data is
> portable, those issues will be all but gone.
>=20
> Moving to compiled C code will kill that feature for good.

Thanks, I understand better now.  So ideally when we change the implement=
ation we'll be able to re-enable this feature.

Cheers,
Cl=E9ment.


--f7Vc96GcbjIC1F8lUCa3lMJG9tJbXIIM9--

--Ix6d17jXXHEeW94fNeqcRdCqdtHo7RNp1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXzyAiAAoJEPqg+cTm90wjxkYQAK0CBw1sEYtit+zoidm0AyHf
9GDoYaim9mQCneYHYq0HPisEevKh8mAGXFgwAXXRQvtAcCT+JnbSC4bN5H0b5sib
a0V1ROlOfCW1szwZy3T2IaqhJtu4gw+QNIgDZk0JOgNHVDUdZ7KMaTp9ziEPqcfC
q8nXvsqPb3u9Y1hUhrArGFduelCJht0PC7TM6UNLfPbWuYaFPH17dXGj3SWJUj6C
4SZDRmmI4sn7NDYNItFrtghXALRO/8GPInzRaQkJGgpUzF2D5C40wx+FyggEJnM7
2y6t2Rt0OGyCwlFAex9XYvnF9oVFFoGcCFTPx5JMCgXB2JzXuOLoRLAUCwIz8Uvr
sgNaqa/KJ6N2HyTEa+AY0Set+aLCYb7324/xof4cRfjaRTRmhXO/OSDu0bLH2AZu
/37JpXqwiKgSfm26VVXNWZxrLdeXY43IIXJptFhoL5DmVJhKQrBb7+0uXS+ibzE+
aLpCO76cEDzeLeUdgd5lLzctmNePaHWwMQHVpTeHwSZnUuTslGb5SCZh116qJPFZ
CoekLBMUWzduU75G6Q1qmz5c9kYMb8azIViFTce2OwcjWIUrEaGIfYkXa9acWZv1
tGLFfGJu0ehCTJ0qLNFkvUQSNMRyZMbucGKPvZJdCPQT6EfNkoLUe+W59tXdigwL
yzgiM2k1G/8ZbX5OwZvb
=vfjN
-----END PGP SIGNATURE-----

--Ix6d17jXXHEeW94fNeqcRdCqdtHo7RNp1--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 19:19:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 06 15:19:20 2016
Received: from localhost ([127.0.0.1]:51733 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhLtw-00013N-9B
	for submit <at> debbugs.gnu.org; Tue, 06 Sep 2016 15:19:20 -0400
Received: from eggs.gnu.org ([208.118.235.92]:58006)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1bhLtv-00013B-6b
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 15:19:19 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1bhLtm-0007jc-UX
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 15:19:14 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59394)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1bhLtm-0007jY-R7; Tue, 06 Sep 2016 15:19:10 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1157
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1bhLtj-0004v2-Ro; Tue, 06 Sep 2016 15:19:10 -0400
Date: Tue, 06 Sep 2016 22:18:39 +0300
Message-Id: <83twdsalbk.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN> (message from
 Paul Eggert on Tue, 6 Sep 2016 11:44:57 -0700)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -6.1 (------)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.1 (------)

> Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
> From: Paul Eggert <eggert@HIDDEN>
> Date: Tue, 6 Sep 2016 11:44:57 -0700
> 
> On 09/06/2016 10:40 AM, Eli Zaretskii wrote:
> > So we will be giving up the ability of end-users to re-dump their
> > Emacs, unless they have a compiler/binutils installed that are
> > compatible with the ones used to build the Emacs binary?
> 
> No, the idea would be to keep the current undump as-is, and to use the 
> new mechanism when building and installing Emacs. That way, end-users 
> would not lose any abilities that they already have. It's OK that new 
> mechanism would work on some platforms where the current undump does not.

Then users on those platforms will never be able to re-dump.

I actually don't understand why the data should be serialized as C
code.  Why not just data that is read into memory (with conversion to
the native format)?  A compiler is not the only way to convert text
into binary data.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 19:12:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 06 15:12:04 2016
Received: from localhost ([127.0.0.1]:51729 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhLmu-0000rV-HM
	for submit <at> debbugs.gnu.org; Tue, 06 Sep 2016 15:12:04 -0400
Received: from eggs.gnu.org ([208.118.235.92]:55701)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1bhLmt-0000r3-C6
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 15:12:03 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1bhLml-00060U-4F
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 15:11:58 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59268)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1bhLml-00060Q-1a; Tue, 06 Sep 2016 15:11:55 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1149
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1bhLmi-0004BM-4r; Tue, 06 Sep 2016 15:11:54 -0400
Date: Tue, 06 Sep 2016 22:11:26 +0300
Message-Id: <83vay8alnl.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Philippe Vaucher <philippe.vaucher@HIDDEN>
In-reply-to: <CAGK7Mr4AsQrG+iKYbhKxfDB73rAhG1fDCzwda7Qqf2KVEYVmUQ@HIDDEN>
 (message from Philippe Vaucher on Tue, 6 Sep 2016 20:24:19 +0200)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <CAGK7Mr68riNa1O70+B+61VfZw=hnfoG9Gk_d-Xfr3s2os=UiSQ@HIDDEN>
 <8337lcc3jf.fsf@HIDDEN>
 <CAGK7Mr4AsQrG+iKYbhKxfDB73rAhG1fDCzwda7Qqf2KVEYVmUQ@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -6.1 (------)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, eggert@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.1 (------)

> From: Philippe Vaucher <philippe.vaucher@HIDDEN>
> Date: Tue, 6 Sep 2016 20:24:19 +0200
> Cc: Paul Eggert <eggert@HIDDEN>, p.stephani2@HIDDEN, 23529 <at> debbugs.gnu.org
> 
> You got me curious, can you explain a bit why it is useful? I always
> thought the reason was about speed, something historical that was
> needed "back then".

If you are loading a lot of code in your init files, you could simply
dump Emacs with all that code loaded.

> AFAIK, nowadays most people that care about speed use autoloads or
> use-package and get under 2-3s of load-time.

Loading a large package can still be slow enough to annoy.  Try
loading Org, for example; then imagine you have several such large
packages to load at startup.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 19:09:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 06 15:09:57 2016
Received: from localhost ([127.0.0.1]:51724 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhLkr-0000o7-4j
	for submit <at> debbugs.gnu.org; Tue, 06 Sep 2016 15:09:57 -0400
Received: from eggs.gnu.org ([208.118.235.92]:55065)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1bhLkq-0000nv-5j
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 15:09:56 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1bhLkh-0005GI-Uc
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 15:09:51 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59246)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1bhLkh-0005G8-RY; Tue, 06 Sep 2016 15:09:47 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1147
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1bhLke-0003xk-2a; Tue, 06 Sep 2016 15:09:46 -0400
Date: Tue, 06 Sep 2016 22:09:20 +0300
Message-Id: <83wpioalr3.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: =?windows-1252?Q?Cl=E9ment?= Pit--Claudel <clement.pit@HIDDEN>
In-reply-to: <07d39d22-0ab8-90c6-e20c-f70d29aa4809@HIDDEN> (message from
 =?windows-1252?Q?Cl=E9ment?= Pit--Claudel on Tue, 6 Sep 2016 14:18:38
 -0400)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN>
 <834m5tapuu.fsf@HIDDEN>
 <07d39d22-0ab8-90c6-e20c-f70d29aa4809@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -6.1 (------)
X-Debbugs-Envelope-To: 23529
Cc: 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.1 (------)

> From: Clément Pit--Claudel <clement.pit@HIDDEN>
> Date: Tue, 6 Sep 2016 14:18:38 -0400
> 
> > So we will be giving up the ability of end-users to re-dump their
> > Emacs, unless they have a compiler/binutils installed that are
> > compatible with the ones used to build the Emacs binary?
> 
> Does this feature exist? I keep seeing complaints about the fact that it was disabled:

AFAIR it was disabled because no one cared to fix its quirks wrt ASLR
etc. (or maybe some similar nuisance).  Once the dumped data is
portable, those issues will be all but gone.

Moving to compiled C code will kill that feature for good.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 19:02:21 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 06 15:02:21 2016
Received: from localhost ([127.0.0.1]:51706 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhLdU-0000c9-0z
	for submit <at> debbugs.gnu.org; Tue, 06 Sep 2016 15:02:21 -0400
Received: from mail-wm0-f46.google.com ([74.125.82.46]:37948)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1bhLdM-0000bn-Eq
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 15:02:18 -0400
Received: by mail-wm0-f46.google.com with SMTP id 1so207116706wmz.1
 for <23529 <at> debbugs.gnu.org>; Tue, 06 Sep 2016 12:02:11 -0700 (PDT)
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; bh=kChzi3V4BGsLzLztS2f1rNkp0g3gk05O9TL4e2Wjy2A=;
 b=zpUBPOqi8kkaMPMY+D27TNNmhW0tDB+h0Fq2c0iTjV8MLgaabKS68m7P8oeHdvY3YJ
 Zd4pyfdpsERQSYMSYCWCBzW3Jp+9Ey7yb+F2b0Ne++IojC6giqG/t2WSRPmUzrjxheD3
 Abx2G3dSxyWZzPkwvtoBy+G0m5/GiJq+MFf7gZaLqMnLN2MkfNmdBUQoVz1exR0r/0aH
 gVmE9AcKzov82t4jBluaCi8DxUCelY/+UP208zDXeR5rPwPWOYzYPnhWFy27m3r3otbC
 iEgvdSYyQdvdmVttgiMOY+OD+KyK7Ytd5GyiTHS7W4bUA9RrIBVtn3d/hGZYF/2gB8co
 xcFQ==
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;
 bh=kChzi3V4BGsLzLztS2f1rNkp0g3gk05O9TL4e2Wjy2A=;
 b=gK/IEMNv9fF7Kmgy6Ap1Extc0tez+APXQBed1doLLvkAtT002FeON+rzct+LpibbeM
 4JeMRZdu//QH/QJqJ+7EDzq27f9c316OXN7cgdj/n3i7UVVOvibXpBXOzyfzto8ebzxm
 a1ZnsUaqKbpjWD2jATsAuQzz4+esx1+w5abcCb65fLBq5fkHCVe2YgufkN6K53q+6yDR
 9srdj+gjg26nSzqrZHc7q7cdgtMRgIojkC/9rsDlWlao5Z98Te6EBQWbgS2Dl4Vn7fs9
 N7BGXGQS6h5YFLFNQHmIARX0gOK4sxh0cUv2zJftJmwJetOvCflZ3D0jcd4dKxv/kfFL
 7fdQ==
X-Gm-Message-State: AE9vXwOKvBOi1Fl7kplis4eytjM7x/ukpMALi3WBqTXRb5OA6Tt8llpQN5gvj7cT4qzO3nwnoyfjsSkOuhK/IA==
X-Received: by 10.28.31.197 with SMTP id f188mr161922wmf.69.1473188524982;
 Tue, 06 Sep 2016 12:02:04 -0700 (PDT)
MIME-Version: 1.0
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <CAGK7Mr68riNa1O70+B+61VfZw=hnfoG9Gk_d-Xfr3s2os=UiSQ@HIDDEN>
 <8337lcc3jf.fsf@HIDDEN>
 <CAArVCkSWzeHTahUKUzXD1=NRDrCskjA-gh5sX14n_ii6mp23Ew@HIDDEN>
 <83zinkanfw.fsf@HIDDEN>
In-Reply-To: <83zinkanfw.fsf@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Tue, 06 Sep 2016 19:01:53 +0000
Message-ID: <CAArVCkQPgxqHR-BTzz4spQn1eTPVSx8VnqpATZU4n_gf3kUUQQ@HIDDEN>
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary=001a114b3e52b80b5f053bdb6efe
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Eli Zaretskii schrieb am Di., 6. Sep. 2016 um 20:33 Uhr: >
 > That will be a bit slower, but that might be OK. > > Slower than compile,
 link, and load? I doubt that. > Not while dumping (nobody cares about the
 dumping speed), but while loading. In the alternative proposal, the dumped
 data could be read directly into the process memory, requiring only some
 relocations. My suggestion would require an extra parsing step on every start.
 [...] Content analysis details:   (1.9 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
 (p.stephani2[at]gmail.com)
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at http://www.dnswl.org/, low
 trust [74.125.82.46 listed in list.dnswl.org]
 2.4 RCVD_IN_SORBS_SPAM     RBL: SORBS: sender is a spam source
 [74.125.82.46 listed in dnsbl.sorbs.net]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
 digit (p.stephani2[at]gmail.com)
 0.0 HTML_MESSAGE           BODY: HTML included in message
 -0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
 [74.125.82.46 listed in wl.mailspike.net]
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid
X-Debbugs-Envelope-To: 23529
Cc: philippe.vaucher@HIDDEN, eggert@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Eli Zaretskii schrieb am Di., 6. Sep. 2016 um 20:33 Uhr: >
    > That will be a bit slower, but that might be OK. > > Slower than compile,
    link, and load? I doubt that. > Not while dumping (nobody cares about the
    dumping speed), but while loading. In the alternative proposal, the dumped
    data could be read directly into the process memory, requiring only some
   relocations. My suggestion would require an extra parsing step on every start.
    [...] 
 
 Content analysis details:   (1.9 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at http://www.dnswl.org/, low
                             trust
                             [74.125.82.46 listed in list.dnswl.org]
  2.4 RCVD_IN_SORBS_SPAM     RBL: SORBS: sender is a spam source
                             [74.125.82.46 listed in dnsbl.sorbs.net]
 -0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
                             [74.125.82.46 listed in wl.mailspike.net]
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail provider
                             (p.stephani2[at]gmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
                             digit (p.stephani2[at]gmail.com)
  0.0 HTML_MESSAGE           BODY: HTML included in message
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
  0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid

--001a114b3e52b80b5f053bdb6efe
Content-Type: text/plain; charset=UTF-8

Eli Zaretskii <eliz@HIDDEN> schrieb am Di., 6. Sep. 2016 um 20:33 Uhr:

> > That will be a bit slower, but that might be OK.
>
> Slower than compile, link, and load?  I doubt that.
>

Not while dumping (nobody cares about the dumping speed), but while
loading. In the alternative proposal, the dumped data could be read
directly into the process memory, requiring only some relocations. My
suggestion would require an extra parsing step on every start.

--001a114b3e52b80b5f053bdb6efe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">Eli Za=
retskii &lt;<a href=3D"mailto:eliz@HIDDEN">eliz@HIDDEN</a>&gt; schrieb am=
 Di., 6. Sep. 2016 um 20:33=C2=A0Uhr:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">&gt; That will be a bit slower, but that might be OK.<br>
<br>
Slower than compile, link, and load?=C2=A0 I doubt that.<br></blockquote><d=
iv><br></div><div>Not while dumping (nobody cares about the dumping speed),=
 but while loading. In the alternative proposal, the dumped data could be r=
ead directly into the process memory, requiring only some relocations. My s=
uggestion would require an extra parsing step on every start.</div><div>=C2=
=A0</div></div></div>

--001a114b3e52b80b5f053bdb6efe--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 18:45:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 06 14:45:45 2016
Received: from localhost ([127.0.0.1]:51697 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhLNR-0000CZ-4C
	for submit <at> debbugs.gnu.org; Tue, 06 Sep 2016 14:45:45 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:47970)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1bhLNP-0000CL-Ok
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 14:45:44 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 05DCA160D74;
 Tue,  6 Sep 2016 11:44:58 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id hPwyyiin8wXC; Tue,  6 Sep 2016 11:44:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5402B16111A;
 Tue,  6 Sep 2016 11:44:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id y880_kxzNHjw; Tue,  6 Sep 2016 11:44:57 -0700 (PDT)
Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 3B9F3160D74;
 Tue,  6 Sep 2016 11:44:57 -0700 (PDT)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Eli Zaretskii <eliz@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <c8e9ebc2-9ddd-bc23-9e24-5d215e2316b4@HIDDEN>
Date: Tue, 6 Sep 2016 11:44:57 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <834m5tapuu.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.1 (-)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.1 (-)

On 09/06/2016 10:40 AM, Eli Zaretskii wrote:
> So we will be giving up the ability of end-users to re-dump their
> Emacs, unless they have a compiler/binutils installed that are
> compatible with the ones used to build the Emacs binary?

No, the idea would be to keep the current undump as-is, and to use the 
new mechanism when building and installing Emacs. That way, end-users 
would not lose any abilities that they already have. It's OK that new 
mechanism would work on some platforms where the current undump does not.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 18:33:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 06 14:33:30 2016
Received: from localhost ([127.0.0.1]:51691 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhLBZ-0008M2-Us
	for submit <at> debbugs.gnu.org; Tue, 06 Sep 2016 14:33:30 -0400
Received: from eggs.gnu.org ([208.118.235.92]:46845)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1bhLBY-0008Lp-9d
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 14:33:28 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1bhLBP-0005pf-TX
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 14:33:23 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58818)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1bhLBP-0005pb-Qp; Tue, 06 Sep 2016 14:33:19 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4958
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1bhLBO-0000WP-1P; Tue, 06 Sep 2016 14:33:19 -0400
Date: Tue, 06 Sep 2016 21:32:51 +0300
Message-Id: <83zinkanfw.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Philipp Stephani <p.stephani2@HIDDEN>
In-reply-to: <CAArVCkSWzeHTahUKUzXD1=NRDrCskjA-gh5sX14n_ii6mp23Ew@HIDDEN>
 (message from Philipp Stephani on Tue, 06 Sep 2016 18:03:13 +0000)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <CAGK7Mr68riNa1O70+B+61VfZw=hnfoG9Gk_d-Xfr3s2os=UiSQ@HIDDEN>
 <8337lcc3jf.fsf@HIDDEN>
 <CAArVCkSWzeHTahUKUzXD1=NRDrCskjA-gh5sX14n_ii6mp23Ew@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -6.1 (------)
X-Debbugs-Envelope-To: 23529
Cc: philippe.vaucher@HIDDEN, eggert@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.1 (------)

> From: Philipp Stephani <p.stephani2@HIDDEN>
> Date: Tue, 06 Sep 2016 18:03:13 +0000
> Cc: eggert@HIDDEN, 23529 <at> debbugs.gnu.org
> 
> If we care enough about this feature, then instead of writing C code we can write some portable serialization
> format (e.g. protobuf).

Something like that, yes.

> That will be a bit slower, but that might be OK. 

Slower than compile, link, and load?  I doubt that.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 18:24:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 06 14:24:59 2016
Received: from localhost ([127.0.0.1]:51686 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhL3L-000882-45
	for submit <at> debbugs.gnu.org; Tue, 06 Sep 2016 14:24:59 -0400
Received: from mail-ua0-f181.google.com ([209.85.217.181]:33757)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philippe.vaucher@HIDDEN>) id 1bhL3K-00087q-7N
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 14:24:58 -0400
Received: by mail-ua0-f181.google.com with SMTP id 31so56412345uao.0
 for <23529 <at> debbugs.gnu.org>; Tue, 06 Sep 2016 11:24:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to
 :cc; bh=dlqAEj6RLoNVqsyLEDxjMTBtT01tnaOvgHQxEBlEtVk=;
 b=xRK/ZmKx7UiK7GOOH5LVwCu7B2NKblyN/YaN7S0FwQG+8tMtImFg4txINGUetjTPQM
 GZ8XeR6sBWOB8asK1F9Rla/Xzr079oybMeVwHhDGPr4culpdiz9Dle7sqaTyePVPi/Dg
 92gYxUwNdQTX9ghhF6CX7VRV7rkiH15ddN1kTRXxJFYrlayjtBiMPJhPQbtUmborO2rp
 PEijagZizdMbiaySjYXe7HWnACHYcxCW1HoMiX7WGNRnzf7qzqDPAX0ZIlONyPXdi9Fe
 fthcjIOpg9TMhnpkZOKfEQry7xvLG98lPSwU7SjmFZr849KpFmb1L30sG8iDrVPV7HeI
 ytJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:in-reply-to:references:from:date
 :message-id:subject:to:cc;
 bh=dlqAEj6RLoNVqsyLEDxjMTBtT01tnaOvgHQxEBlEtVk=;
 b=lZFzLIUVtCccsfkh/eOR82/aIiFCHcTFkNIt5Z8ebNE7jSc8b04vogmBPGp0RquPVx
 20sKA9kFA/VFpD4aCKaPO3oaVvZUhS3ScVGt0TFbKte2xZ6T75ay75kx6MQMpzE5TwQD
 7RADgJdODKllpG3HzE+vEtRCo6IWu8AeMzXEbYMDW1RoatDUKFLEKiSb4/zMUslENexg
 XKwQbAIt9rUknKVJdqeRyTE0n7IrZmQrkRUsV2crvalHRgoDUiM1a6VtkNTlP3DIqU6r
 1TNvlttu3XYPVE5112JsJsV0vFV2pGaTvJV216YOrsqFVwti2xjNDbkdwLjEdn638ZN1
 sjZQ==
X-Gm-Message-State: AE9vXwPye/ufet5D2UQhegIsX00Bf7ftIlZJKy02sqNLIBv0C8u3syjuKhaF+csJPl2H6ZGf7xKcydlvJ3q/9A==
X-Received: by 10.159.36.4 with SMTP id 4mr25890605uaq.71.1473186292747; Tue,
 06 Sep 2016 11:24:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.44.18 with HTTP; Tue, 6 Sep 2016 11:24:19 -0700 (PDT)
In-Reply-To: <8337lcc3jf.fsf@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <CAGK7Mr68riNa1O70+B+61VfZw=hnfoG9Gk_d-Xfr3s2os=UiSQ@HIDDEN>
 <8337lcc3jf.fsf@HIDDEN>
From: Philippe Vaucher <philippe.vaucher@HIDDEN>
Date: Tue, 6 Sep 2016 20:24:19 +0200
Message-ID: <CAGK7Mr4AsQrG+iKYbhKxfDB73rAhG1fDCzwda7Qqf2KVEYVmUQ@HIDDEN>
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, Paul Eggert <eggert@HIDDEN>,
 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

>> I doubt many end-users are aware of this feature, let alone use it.
>
> Rarely used is not the same as useless and unneeded.  Whenever you
> remove a feature, expect someone to come up with complaints about
> regressions.

You got me curious, can you explain a bit why it is useful? I always
thought the reason was about speed, something historical that was
needed "back then".

AFAIK, nowadays most people that care about speed use autoloads or
use-package and get under 2-3s of load-time. Don't get me wrong I
understand that dumping emacs is much faster (< 1s load time), but the
cost of having to re-dump each time you add a package makes it not
very practical.

Maybe one of the advantage is when you want to carry your customized
emacs as one file on some USB key?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 6 Sep 2016 18:18:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 06 14:18:54 2016
Received: from localhost ([127.0.0.1]:51682 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhKxS-0007yn-DI
	for submit <at> debbugs.gnu.org; Tue, 06 Sep 2016 14:18:54 -0400
Received: from eggs.gnu.org ([208.118.235.92]:43635)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <clement.pit@HIDDEN>) id 1bhKxQ-0007yY-80
 for submit <at> debbugs.gnu.org; Tue, 06 Sep 2016 14:18:52 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <clement.pit@HIDDEN>) id 1bhKxK-0002uz-AJ
 for submit <at> debbugs.gnu.org; Tue, 06 Sep 2016 14:18:47 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_20,FREEMAIL_FROM
 autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:54553)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <clement.pit@HIDDEN>) id 1bhKxK-0002ul-6t
 for submit <at> debbugs.gnu.org; Tue, 06 Sep 2016 14:18:46 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:34599)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <clement.pit@HIDDEN>) id 1bhKxI-0001nR-8B
 for bug-gnu-emacs@HIDDEN; Tue, 06 Sep 2016 14:18:45 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <clement.pit@HIDDEN>) id 1bhKxE-0002ts-UM
 for bug-gnu-emacs@HIDDEN; Tue, 06 Sep 2016 14:18:44 -0400
Received: from mout.kundenserver.de ([212.227.126.187]:59219)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <clement.pit@HIDDEN>) id 1bhKxE-0002tM-Jo
 for bug-gnu-emacs@HIDDEN; Tue, 06 Sep 2016 14:18:40 -0400
Received: from [18.189.22.67] ([18.189.22.67]) by mrelayeu.kundenserver.de
 (mreue001) with ESMTPSA (Nemesis) id 0Lst3q-1awpAD2qD4-012cJq for
 <bug-gnu-emacs@HIDDEN>; Tue, 06 Sep 2016 20:18:39 +0200
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: bug-gnu-emacs@HIDDEN
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= <clement.pit@HIDDEN>
Message-ID: <07d39d22-0ab8-90c6-e20c-f70d29aa4809@HIDDEN>
Date: Tue, 6 Sep 2016 14:18:38 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <834m5tapuu.fsf@HIDDEN>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="TuN4vjrH5HdeDKRvFKCl2MULBMnk0f2R1"
X-Provags-ID: V03:K0:7zJN5AwfibM2dgS2HBIDgUhnZApRHEgGxJv4re9ekZXZoUUkaie
 QuYdjfMgMG8Fa3sQOcmcbw+FEHiLKoX3gXxrjf6HLGBX83Hh4HlmOyjOGaNrRafWauNaBy5
 nRIi4heLL6GF7wViCgDZi3DBQjIzTSmT0y6jAw8tD/Sl1mjW7kRMHHZEVEyGlNLj5MkbjHd
 jEb66C/f2Kble2m5J4NzA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:UE4oO7mF+Xs=:ADyJ0bgdwcqFZDasruOttB
 er3mDIXCgWBPONBo6nzfoxFqAe4So4Mm9ZN7UgmbpHhAnRXQt1Ho9N/ng4YU2/FSra4wYbDoU
 CbLhJnBhrCNar6SqYm29UEu3Be8M0vCo+CnJkbYSQ3yhsMCjYZ7qHlJsLskmRDMtNZnqL99Jl
 AW6r+PK5IGrgO4Y4MwQctJUOZNWecUk9s7x/2nXUosupaa1602Z2PWgPKo8RPpKKEx7Eo1M9U
 IDzD6uELOOdF1Z3eAU/wE7syWt8m5kG8OZP9Yvk4/7ujNHvgqJL33L4sA9CGpPsXG4j9wUTwR
 iWicomGi/PoVs4IxA+9zypMF+wXteGj+tUlnO4HC2M7UKEMNZdSn/CZ9n6mjHD/nsvFDr74nZ
 T/zlPC4nI4wqEOgutSRGuvLC0J/DCEf3JOuiFj7JPqxme33yQJbxPFG+9xkaynHooVOHkY6Df
 teetdOZREhnEz3sK5tDwhw83q7fnbnnlvCHJ1d2E0YCpPhEUy8X5rjwzsccGS4MUGAFPsqCfy
 VzJEHrjb/GzNvqvIxRymkWpcS9ZGXyuobVELrwXtW5Pbd06GHiU8sPponfwqTponR29hEE2Dl
 WOOWKo+ag83ZeadIRW8OIL26YN0mGYZXGU7TM85V5OmMt8/8k71ywPdDEmTbgRskz36fmBJyf
 7058ZDCKjxuj01N9HC8kE7FW+frbB5ryzyAgM6kbdk4Gv9VmnVvfpL6bms6yD04papnY=
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -4.0 (----)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.0 (----)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--TuN4vjrH5HdeDKRvFKCl2MULBMnk0f2R1
Content-Type: multipart/mixed; boundary="rP4hdKraqLsudlN4srmXmpJwcECgOLFOL";
 protected-headers="v1"
From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= <clement.pit@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Message-ID: <07d39d22-0ab8-90c6-e20c-f70d29aa4809@HIDDEN>
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
In-Reply-To: <834m5tapuu.fsf@HIDDEN>

--rP4hdKraqLsudlN4srmXmpJwcECgOLFOL
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 2016-09-06 13:40, Eli Zaretskii wrote:
>> From: Paul Eggert <eggert@HIDDEN>
>> Date: Tue, 6 Sep 2016 10:21:15 -0700
>> Cc: 23529 <at> debbugs.gnu.org
>>
>> My idea is pretty simple: just output the objects as a C file, then=20
>> compile and link the file.
>=20
> So we will be giving up the ability of end-users to re-dump their
> Emacs, unless they have a compiler/binutils installed that are
> compatible with the ones used to build the Emacs binary?

Does this feature exist? I keep seeing complaints about the fact that it =
was disabled:

    $ emacs -Q --batch --eval '(dump-emacs "a" "b")'
    Emacs can be dumped only once

Or am I misunderstanding your point?

Cl=E9ment.



--rP4hdKraqLsudlN4srmXmpJwcECgOLFOL--

--TuN4vjrH5HdeDKRvFKCl2MULBMnk0f2R1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXzwh+AAoJEPqg+cTm90wja8MQAJ6DcbkV319iaNVLWfgOa43+
AJpebfVyl6Z3Q9+nzSCqQYTOCgCdyT3Fl0ZBJFmDA+vClJ1ycUi0Vcu0RgtfBLK8
Gv6pUf3PIM5QIAgATAK7ScO4Vs98t+UL9LjbiL0LrSYxzfqQjyErb6nng0gIwLCu
YKCgbbdcglNaj5N97+yOFmwmqwVpxlrAwSVlMzjd01APqBKIVqpaBcekWkyRLI0f
Q16fs2SgDPLAIW1znOl1biFpUlm9ddV+6w/338oe4DnU9ANNsonVBceeOn4MqBb5
75+3AQBAB21MJuEXySX58Ic+VDZeoOynmRqCzo3N4ZM1JtTIBTStAeptxAzJFVww
zLIPmLqalaGtFBvQ2+4itjeSLAO0P7c5RqtK15ccOlK9GNbhggP+Ckloa2kjgiKx
SNhfdQ/a7cYPvC1wlwYmblnlvhG0gjJRDmbwFHbP58wWBPjVU/kxsHyWvzZNIvg8
HRWA2PN7febYZa2lIaq7gcOwa8A06QKJwbK2xRLCEhzdoeVisFlpeFUivo7s16j1
iY8EuQiO+Im16OyRQCHKr0ICJOzQ7J2LE9ksaIyzwDsIPA0iRixpoZ/7gZn/c/XX
2hFXtnsfNmnxmZ5xhRZXuUELrTHD5I85QsrBFfrq+tA4x/YTuR1sURI50zJwKN0n
U5Q6U7F6CLqzgg8GvH/E
=PFuZ
-----END PGP SIGNATURE-----

--TuN4vjrH5HdeDKRvFKCl2MULBMnk0f2R1--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 18:05:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 06 14:05:14 2016
Received: from localhost ([127.0.0.1]:51672 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhKkD-0007eo-Su
	for submit <at> debbugs.gnu.org; Tue, 06 Sep 2016 14:05:14 -0400
Received: from eggs.gnu.org ([208.118.235.92]:41106)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1bhKkC-0007eT-BB
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 14:05:12 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1bhKk3-0000S4-Js
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 14:05:07 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58500)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1bhKk3-0000Ro-GL; Tue, 06 Sep 2016 14:05:03 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4943
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1bhKjz-00043h-IW; Tue, 06 Sep 2016 14:05:02 -0400
Date: Tue, 06 Sep 2016 21:04:31 +0300
Message-Id: <831t0wc3bk.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Philipp Stephani <p.stephani2@HIDDEN>
In-reply-to: <CAArVCkTE0P6HL7F0kSJY4DyvDnAns0rnyTzeHJ-+nMxLaWUziw@HIDDEN>
 (message from Philipp Stephani on Tue, 06 Sep 2016 17:55:42 +0000)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <CAGK7Mr68riNa1O70+B+61VfZw=hnfoG9Gk_d-Xfr3s2os=UiSQ@HIDDEN>
 <CAArVCkTE0P6HL7F0kSJY4DyvDnAns0rnyTzeHJ-+nMxLaWUziw@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -6.1 (------)
X-Debbugs-Envelope-To: 23529
Cc: philippe.vaucher@HIDDEN, eggert@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.1 (------)

> From: Philipp Stephani <p.stephani2@HIDDEN>
> Date: Tue, 06 Sep 2016 17:55:42 +0000
> Cc: Paul Eggert <eggert@HIDDEN>, 23529 <at> debbugs.gnu.org
> 
>  IMHO, a saner compile cycle & the ability to play nice with modern
>  systems (ASLR, containers) largely outweights the loss of this
>  feature.
> 
> I agree. 

Why not look for ways of having the cake and eating it, too?  There's
no reason to believe there couldn't be a way to play nice with modern
systems without losing any existing feature.  After all, what we dump
is just data, we just cannot safely write it into the executable file.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 18:03:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 06 14:03:31 2016
Received: from localhost ([127.0.0.1]:51667 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhKiZ-0007c3-Gq
	for submit <at> debbugs.gnu.org; Tue, 06 Sep 2016 14:03:31 -0400
Received: from mail-wm0-f46.google.com ([74.125.82.46]:37935)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1bhKiX-0007bp-UV
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 14:03:30 -0400
Received: by mail-wm0-f46.google.com with SMTP id 1so204478022wmz.1
 for <23529 <at> debbugs.gnu.org>; Tue, 06 Sep 2016 11:03:29 -0700 (PDT)
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; bh=/L7cNahKO9aGfyKUwbm4qFs3Ocp5vbDllM7ACSjncfY=;
 b=k3XXJ89jYssFH/OM0SXuwKDoTT4ViA4YtwGxFNmgXo6U3tnYhhJ4uttyIH6bIhIxxk
 iAWVzXchwpxp9mWPc+E9Rw7HLyhhmhjlyH9AA+HqBDkyC2ErbosLJ19bnlQMi23as28h
 6lWUkpfNK+WLE9O5ZtqgrcZKFPWuU4SgnMAxr/A106iqsx9EJP0tyjCOX0acAfVJptwl
 Q6jqLkuIQBaNOD1jjPUT8dG+SnnYFbaX4nXwykpnLI/INP3ik0WwUge+X8LDG7GsJHNu
 Cey+nBXNrXl7qQVj8CUVgWXrSsRgSj5sGgmysxLjoIxsVPtP8vLNYf+hpILeF6aDgzt3
 cXuQ==
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;
 bh=/L7cNahKO9aGfyKUwbm4qFs3Ocp5vbDllM7ACSjncfY=;
 b=mf4tgv5GP5JxirdX02rUTsEacn66KG/pB61MXFG+ovZhtMCzI2vy/ZjDjazA7VJdQj
 CneKZ27F356RNwUw44VLq1qgOAS33do0s+pLh8YL5gJxV+sgnI+Fz0Hl2vakNyq4kk7E
 ZH4+yIg4ms5r2IuO4Npf7vMHcslv+1SwZsTcEK0InxD9KxL4xoJ3h4AsK3vPCwj52TiH
 7Kjz6n4Up1Mz756SFFMC/EMaVPtp99h5q7CbZQhinNP/Et3/1XR6wVpBifNIhipsjM17
 HZvR6mv7l6aK+xDNDg+z9sVhrU2ZWqVttb45dRfI11k3BwjmQ1qxoTvyd3ZoKvkQJMki
 ihzw==
X-Gm-Message-State: AE9vXwMDfv2F4PmpmJxWYYqhMHOdda7prAivhcAmCUH6W05bAYqFagHrDjMFgjxc/bgVQfMF5WxUOAfuy/J9DA==
X-Received: by 10.194.184.39 with SMTP id er7mr37635483wjc.159.1473185004322; 
 Tue, 06 Sep 2016 11:03:24 -0700 (PDT)
MIME-Version: 1.0
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <CAGK7Mr68riNa1O70+B+61VfZw=hnfoG9Gk_d-Xfr3s2os=UiSQ@HIDDEN>
 <8337lcc3jf.fsf@HIDDEN>
In-Reply-To: <8337lcc3jf.fsf@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Tue, 06 Sep 2016 18:03:13 +0000
Message-ID: <CAArVCkSWzeHTahUKUzXD1=NRDrCskjA-gh5sX14n_ii6mp23Ew@HIDDEN>
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Eli Zaretskii <eliz@HIDDEN>, Philippe Vaucher <philippe.vaucher@HIDDEN>
Content-Type: multipart/alternative; boundary=047d7ba97a10df0999053bda9c92
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Eli Zaretskii schrieb am Di., 6. Sep. 2016 um 20:00 Uhr: >
 > From: Philippe Vaucher > > Date: Tue, 6 Sep 2016 19:46:47 +0200 > > Cc:
 Paul Eggert , p.stephani2@HIDDEN, > 23529 <at> debbugs.gnu.org > > > > >> My
 idea is pretty simple: just output the objects as a C file, then > > >> compile
 and link the file. > > > > > > So we will be giving up the ability of
 end-users
 to re-dump their > > > Emacs, unless they have a compiler/binutils installed
 that are > > > compatible with the ones used to build the Emacs binary? >
 > > > I doubt many end-users are aware of this feature, let alone use it.
 > > Rarely used is not the same as useless and unneeded. Whenever you > remove
 a feature, expect someone to come up with complaints about > regressions.
 > [...] Content analysis details:   (1.9 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 2.4 RCVD_IN_SORBS_SPAM     RBL: SORBS: sender is a spam source
 [74.125.82.46 listed in dnsbl.sorbs.net]
 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
 (p.stephani2[at]gmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
 digit (p.stephani2[at]gmail.com)
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at http://www.dnswl.org/, low
 trust [74.125.82.46 listed in list.dnswl.org]
 0.0 HTML_MESSAGE           BODY: HTML included in message
 -0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
 [74.125.82.46 listed in wl.mailspike.net]
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid
X-Debbugs-Envelope-To: 23529
Cc: 23529 <at> debbugs.gnu.org, eggert@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Eli Zaretskii schrieb am Di., 6. Sep. 2016 um 20:00 Uhr: >
    > From: Philippe Vaucher > > Date: Tue, 6 Sep 2016 19:46:47 +0200 > > Cc:
    Paul Eggert , p.stephani2@HIDDEN, > 23529 <at> debbugs.gnu.org > > > > >> My
    idea is pretty simple: just output the objects as a C file, then > > >> compile
    and link the file. > > > > > > So we will be giving up the ability of end-users
    to re-dump their > > > Emacs, unless they have a compiler/binutils installed
    that are > > > compatible with the ones used to build the Emacs binary? >
    > > > I doubt many end-users are aware of this feature, let alone use it.
    > > Rarely used is not the same as useless and unneeded. Whenever you > remove
    a feature, expect someone to come up with complaints about > regressions.
    > [...] 
 
 Content analysis details:   (1.9 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at http://www.dnswl.org/, low
                             trust
                             [74.125.82.46 listed in list.dnswl.org]
  2.4 RCVD_IN_SORBS_SPAM     RBL: SORBS: sender is a spam source
                             [74.125.82.46 listed in dnsbl.sorbs.net]
 -0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
                             [74.125.82.46 listed in wl.mailspike.net]
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail provider
                             (p.stephani2[at]gmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
                             digit (p.stephani2[at]gmail.com)
  0.0 HTML_MESSAGE           BODY: HTML included in message
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
  0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid

--047d7ba97a10df0999053bda9c92
Content-Type: text/plain; charset=UTF-8

Eli Zaretskii <eliz@HIDDEN> schrieb am Di., 6. Sep. 2016 um 20:00 Uhr:

> > From: Philippe Vaucher <philippe.vaucher@HIDDEN>
> > Date: Tue, 6 Sep 2016 19:46:47 +0200
> > Cc: Paul Eggert <eggert@HIDDEN>, p.stephani2@HIDDEN,
> 23529 <at> debbugs.gnu.org
> >
> > >> My idea is pretty simple: just output the objects as a C file, then
> > >> compile and link the file.
> > >
> > > So we will be giving up the ability of end-users to re-dump their
> > > Emacs, unless they have a compiler/binutils installed that are
> > > compatible with the ones used to build the Emacs binary?
> >
> > I doubt many end-users are aware of this feature, let alone use it.
>
> Rarely used is not the same as useless and unneeded.  Whenever you
> remove a feature, expect someone to come up with complaints about
> regressions.
>

If we care enough about this feature, then instead of writing C code we can
write some portable serialization format (e.g. protobuf). That will be a
bit slower, but that might be OK.

--047d7ba97a10df0999053bda9c92
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">Eli Za=
retskii &lt;<a href=3D"mailto:eliz@HIDDEN">eliz@HIDDEN</a>&gt; schrieb am=
 Di., 6. Sep. 2016 um 20:00=C2=A0Uhr:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">&gt; From: Philippe Vaucher &lt;<a href=3D"mailto:philippe.vaucher@gmail=
.com" target=3D"_blank">philippe.vaucher@HIDDEN</a>&gt;<br>
&gt; Date: Tue, 6 Sep 2016 19:46:47 +0200<br>
&gt; Cc: Paul Eggert &lt;<a href=3D"mailto:eggert@HIDDEN" target=3D"_b=
lank">eggert@HIDDEN</a>&gt;, <a href=3D"mailto:p.stephani2@HIDDEN" =
target=3D"_blank">p.stephani2@HIDDEN</a>, <a href=3D"mailto:23529@debbug=
s.gnu.org" target=3D"_blank">23529 <at> debbugs.gnu.org</a><br>
&gt;<br>
&gt; &gt;&gt; My idea is pretty simple: just output the objects as a C file=
, then<br>
&gt; &gt;&gt; compile and link the file.<br>
&gt; &gt;<br>
&gt; &gt; So we will be giving up the ability of end-users to re-dump their=
<br>
&gt; &gt; Emacs, unless they have a compiler/binutils installed that are<br=
>
&gt; &gt; compatible with the ones used to build the Emacs binary?<br>
&gt;<br>
&gt; I doubt many end-users are aware of this feature, let alone use it.<br=
>
<br>
Rarely used is not the same as useless and unneeded.=C2=A0 Whenever you<br>
remove a feature, expect someone to come up with complaints about<br>
regressions.<br></blockquote><div><br></div><div>If we care enough about th=
is feature, then instead of writing C code we can write some portable seria=
lization format (e.g. protobuf). That will be a bit slower, but that might =
be OK.=C2=A0</div></div></div>

--047d7ba97a10df0999053bda9c92--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 18:00:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 06 14:00:32 2016
Received: from localhost ([127.0.0.1]:51663 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhKfg-0007Xg-0A
	for submit <at> debbugs.gnu.org; Tue, 06 Sep 2016 14:00:32 -0400
Received: from eggs.gnu.org ([208.118.235.92]:38383)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1bhKfd-0007XQ-5n
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 14:00:31 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1bhKfT-0007Ct-Hf
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 14:00:24 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58410)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1bhKfT-0007Ci-E1; Tue, 06 Sep 2016 14:00:19 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4941
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1bhKfP-0004Jn-G7; Tue, 06 Sep 2016 14:00:17 -0400
Date: Tue, 06 Sep 2016 20:59:48 +0300
Message-Id: <8337lcc3jf.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Philippe Vaucher <philippe.vaucher@HIDDEN>
In-reply-to: <CAGK7Mr68riNa1O70+B+61VfZw=hnfoG9Gk_d-Xfr3s2os=UiSQ@HIDDEN>
 (message from Philippe Vaucher on Tue, 6 Sep 2016 19:46:47 +0200)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <CAGK7Mr68riNa1O70+B+61VfZw=hnfoG9Gk_d-Xfr3s2os=UiSQ@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -6.1 (------)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, eggert@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.1 (------)

> From: Philippe Vaucher <philippe.vaucher@HIDDEN>
> Date: Tue, 6 Sep 2016 19:46:47 +0200
> Cc: Paul Eggert <eggert@HIDDEN>, p.stephani2@HIDDEN, 23529 <at> debbugs.gnu.org
> 
> >> My idea is pretty simple: just output the objects as a C file, then
> >> compile and link the file.
> >
> > So we will be giving up the ability of end-users to re-dump their
> > Emacs, unless they have a compiler/binutils installed that are
> > compatible with the ones used to build the Emacs binary?
> 
> I doubt many end-users are aware of this feature, let alone use it.

Rarely used is not the same as useless and unneeded.  Whenever you
remove a feature, expect someone to come up with complaints about
regressions.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 17:55:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 06 13:55:59 2016
Received: from localhost ([127.0.0.1]:51659 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhKbH-0007PU-FB
	for submit <at> debbugs.gnu.org; Tue, 06 Sep 2016 13:55:59 -0400
Received: from mail-wm0-f48.google.com ([74.125.82.48]:38398)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1bhKbG-0007PG-LI
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 13:55:58 -0400
Received: by mail-wm0-f48.google.com with SMTP id 1so204130554wmz.1
 for <23529 <at> debbugs.gnu.org>; Tue, 06 Sep 2016 10:55:58 -0700 (PDT)
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; bh=8mZBpcxf3GmNY7d+XvZajOnhSOFCFCkq32YZxcD9pyY=;
 b=RnZlOa9U/ZAYidCfKOTi9neRJfFYt8+ODCrTlOFlkAKRkwjH2/e2dlqHTbZD/dq6ds
 SjzyFceXv3KLulH21n2WRDpaET7livpTgqPiOi4ZjQ19kbvt8qCdUChOt37m1frcWReQ
 u+QIgdOzseCNSa+7iEd4Z1R+a6Hu0p67gFy3rwK9mgtNg5GYZsncp6WTDaNLfkQ18+SR
 5mdUQdMB9KQxOxLxhIueJxlC+U9rwD5Czx8xkjAgx3VncDBtfRxeCkvkDGJDAMGKNHnf
 RTiSOJ8xEH/b4atjU0INY1X3LtxL8wtRNKrXbQjPT1me8yjAVYvS7z+GBhSlGfFXI3Qe
 VK0Q==
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;
 bh=8mZBpcxf3GmNY7d+XvZajOnhSOFCFCkq32YZxcD9pyY=;
 b=LVBGzwQWWOWmWGSKExZCE7BWGtKdjr5zjCQ+0TiLTgqUpHXau+s8TQBzvPANy78gro
 RO+ReZXM3CXZ2quO8rS7Z659mUqL8BQXaLTjz3sXL/GwfcBCEI9B71M+KIJ5kofvNoy2
 Q9TmnbiL0FOtBHqwDcOeBhCuzATKfmj6q941C9RtIFSsvt3kDeuT+ZOpU0bxE3DjLsKN
 YZ+doliZfG2bglMHUhg9thsH+DZLRG6l7asMqmc3S7nu7lZO1eEZpllQDdnpRZokJPjy
 UyYlbuagSPba39nSm/zAgYgnr56jFF6Bt3wxOaEW8gFnXnn+4b4v/10CB3pYI8tQQCXw
 7ohQ==
X-Gm-Message-State: AE9vXwNyRsdNlR10T/czcX+ewn2HhhaVQXYvMZsBjG+nfBxLdnQ2+W3C5YdlhgYh1ymiANLIjsovQ6+9sOSTDQ==
X-Received: by 10.194.87.169 with SMTP id az9mr23624412wjb.81.1473184552933;
 Tue, 06 Sep 2016 10:55:52 -0700 (PDT)
MIME-Version: 1.0
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
 <CAGK7Mr68riNa1O70+B+61VfZw=hnfoG9Gk_d-Xfr3s2os=UiSQ@HIDDEN>
In-Reply-To: <CAGK7Mr68riNa1O70+B+61VfZw=hnfoG9Gk_d-Xfr3s2os=UiSQ@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Tue, 06 Sep 2016 17:55:42 +0000
Message-ID: <CAArVCkTE0P6HL7F0kSJY4DyvDnAns0rnyTzeHJ-+nMxLaWUziw@HIDDEN>
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Philippe Vaucher <philippe.vaucher@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary=047d7b10c7e7f75fdd053bda814e
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Philippe Vaucher schrieb am Di., 6. Sep. 2016 um 19:47 Uhr:
 > >> My idea is pretty simple: just output the objects as a C file, then
 > >> compile and link the file. > > > > So we will be giving up the ability
 of end-users to re-dump their > > Emacs, unless they have a compiler/binutils
 installed that are > > compatible with the ones used to build the Emacs
 binary?
 > > I doubt many end-users are aware of this feature, let alone use it. >
 > IMHO, a saner compile cycle & the ability to play nice with modern > systems
 (ASLR, containers) largely outweights the loss of this > feature. > > I agree.
 [...] Content analysis details:   (1.9 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
 (p.stephani2[at]gmail.com)
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at http://www.dnswl.org/, low
 trust [74.125.82.48 listed in list.dnswl.org]
 2.4 RCVD_IN_SORBS_SPAM     RBL: SORBS: sender is a spam source
 [74.125.82.48 listed in dnsbl.sorbs.net]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
 digit (p.stephani2[at]gmail.com)
 -0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
 [74.125.82.48 listed in wl.mailspike.net]
 0.0 HTML_MESSAGE           BODY: HTML included in message
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid
X-Debbugs-Envelope-To: 23529
Cc: 23529 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Philippe Vaucher schrieb am Di., 6. Sep. 2016 um 19:47 Uhr:
    > >> My idea is pretty simple: just output the objects as a C file, then
   > >> compile and link the file. > > > > So we will be giving up the ability
    of end-users to re-dump their > > Emacs, unless they have a compiler/binutils
    installed that are > > compatible with the ones used to build the Emacs binary?
    > > I doubt many end-users are aware of this feature, let alone use it. >
    > IMHO, a saner compile cycle & the ability to play nice with modern > systems
    (ASLR, containers) largely outweights the loss of this > feature. > > I agree.
    [...] 
 
 Content analysis details:   (1.9 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at http://www.dnswl.org/, low
                             trust
                             [74.125.82.48 listed in list.dnswl.org]
  2.4 RCVD_IN_SORBS_SPAM     RBL: SORBS: sender is a spam source
                             [74.125.82.48 listed in dnsbl.sorbs.net]
 -0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
                             [74.125.82.48 listed in wl.mailspike.net]
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail provider
                             (p.stephani2[at]gmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
                             digit (p.stephani2[at]gmail.com)
  0.0 HTML_MESSAGE           BODY: HTML included in message
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
  0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid

--047d7b10c7e7f75fdd053bda814e
Content-Type: text/plain; charset=UTF-8

Philippe Vaucher <philippe.vaucher@HIDDEN> schrieb am Di., 6. Sep. 2016
um 19:47 Uhr:

> >> My idea is pretty simple: just output the objects as a C file, then
> >> compile and link the file.
> >
> > So we will be giving up the ability of end-users to re-dump their
> > Emacs, unless they have a compiler/binutils installed that are
> > compatible with the ones used to build the Emacs binary?
>
> I doubt many end-users are aware of this feature, let alone use it.
>
> IMHO, a saner compile cycle & the ability to play nice with modern
> systems (ASLR, containers) largely outweights the loss of this
> feature.
>
>
I agree.

--047d7b10c7e7f75fdd053bda814e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">Philip=
pe Vaucher &lt;<a href=3D"mailto:philippe.vaucher@HIDDEN">philippe.vauch=
er@HIDDEN</a>&gt; schrieb am Di., 6. Sep. 2016 um 19:47=C2=A0Uhr:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">&gt;&gt; My idea is pretty simple: just o=
utput the objects as a C file, then<br>
&gt;&gt; compile and link the file.<br>
&gt;<br>
&gt; So we will be giving up the ability of end-users to re-dump their<br>
&gt; Emacs, unless they have a compiler/binutils installed that are<br>
&gt; compatible with the ones used to build the Emacs binary?<br>
<br>
I doubt many end-users are aware of this feature, let alone use it.<br>
<br>
IMHO, a saner compile cycle &amp; the ability to play nice with modern<br>
systems (ASLR, containers) largely outweights the loss of this<br>
feature.<br>
<br></blockquote><div><br></div><div>I agree.=C2=A0</div></div></div>

--047d7b10c7e7f75fdd053bda814e--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 17:47:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 06 13:47:26 2016
Received: from localhost ([127.0.0.1]:51654 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhKT0-0007DP-LR
	for submit <at> debbugs.gnu.org; Tue, 06 Sep 2016 13:47:26 -0400
Received: from mail-vk0-f47.google.com ([209.85.213.47]:36671)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philippe.vaucher@HIDDEN>) id 1bhKSy-0007D7-8a
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 13:47:24 -0400
Received: by mail-vk0-f47.google.com with SMTP id w64so18127084vkh.3
 for <23529 <at> debbugs.gnu.org>; Tue, 06 Sep 2016 10:47:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to
 :cc; bh=lu7z3dauBHZmBCntWnwDVLj2V3ifbWLAAxfqUuFgB7Q=;
 b=qIUiAybXsAIzVA+A6+pa7BHUmySZkI0KwKSycol44aV9nxIRHptXkMLen7NavOjCck
 beCpg79mkt9oNWFajSR3nCa5X2ySvUm/Cxup92hozZb9VDRlZ7yQc7hXwes/2ESX2kGx
 7mO5561+BrKnPhwiaHc51ksoTxDM2W9JIbb6wpU14zigbHhi+9v7InILnYl3CU3k7Suy
 r2W/Lsj370mCA4XxmtgyDugRfle+Hrc+eolnkCljCRMf1fncJ25TTEjpUZl+35uSMyRQ
 fEpg1mwAd00RwnlSKsuLLgtIuhYpgWyIgZM5SIiuVu+gEmOUVQpUNqHNPAgCVAOdeH7R
 bL4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:in-reply-to:references:from:date
 :message-id:subject:to:cc;
 bh=lu7z3dauBHZmBCntWnwDVLj2V3ifbWLAAxfqUuFgB7Q=;
 b=Edx+9PGMWY7E52iZ3iKbAh6Ge57nYoVHwB7DrulQuTCt9Izu6ky0NQSP80SGZcvr3m
 jkmdnV4WA1Bpm/WCT5iD50HZWmncW+I0tP/kO2lrvVdodj29QMmOXJX1MzanPLmTw95/
 Iq2140IMlFqqHuIOCk4nfl1rb/cLz+xRLUd+eOrrwg7eg+LAhOgMk5uD4bndtbbo5RBS
 4cStXNd5MgDVrq/mq6KDVJDMe9oV0xedBi119bCMpjUobU9lyNrzMjADMLnAI8OhsSC1
 zlfyyTXOThr4ST9mJ0P+FNGGmdmXvt8WYo38MgXywpz5kWyUELoh2OXFEUYP4ZYgCb75
 oerA==
X-Gm-Message-State: AE9vXwNPXEV5g1r/OANRZaGECqFqttDJ7JTMjbrcn+H53odnoi5Z6mJTqimY4tjYQpPwShsF4ToHCIN3DaGDFQ==
X-Received: by 10.31.138.74 with SMTP id m71mr25437155vkd.4.1473184038414;
 Tue, 06 Sep 2016 10:47:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.44.18 with HTTP; Tue, 6 Sep 2016 10:46:47 -0700 (PDT)
In-Reply-To: <834m5tapuu.fsf@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> <834m5tapuu.fsf@HIDDEN>
From: Philippe Vaucher <philippe.vaucher@HIDDEN>
Date: Tue, 6 Sep 2016 19:46:47 +0200
Message-ID: <CAGK7Mr68riNa1O70+B+61VfZw=hnfoG9Gk_d-Xfr3s2os=UiSQ@HIDDEN>
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: 1.7 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  >> My idea is pretty simple: just output the objects as a
 C file, then >> compile and link the file. > > So we will be giving up the
 ability of end-users to re-dump their > Emacs,
 unless they have a compiler/binutils
 installed that are > compatible with the ones used to build the Emacs binary?
 [...] Content analysis details:   (1.7 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 2.4 RCVD_IN_SORBS_SPAM     RBL: SORBS: sender is a spam source
 [209.85.213.47 listed in dnsbl.sorbs.net]
 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
 (philippe.vaucher[at]gmail.com)
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at http://www.dnswl.org/, low
 trust [209.85.213.47 listed in list.dnswl.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
 [209.85.213.47 listed in wl.mailspike.net]
 0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, Paul Eggert <eggert@HIDDEN>,
 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.7 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  >> My idea is pretty simple: just output the objects as a
   C file, then >> compile and link the file. > > So we will be giving up the
    ability of end-users to re-dump their > Emacs, unless they have a compiler/binutils
    installed that are > compatible with the ones used to build the Emacs binary?
    [...] 
 
 Content analysis details:   (1.7 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at http://www.dnswl.org/, low
                             trust
                             [209.85.213.47 listed in list.dnswl.org]
  2.4 RCVD_IN_SORBS_SPAM     RBL: SORBS: sender is a spam source
                             [209.85.213.47 listed in dnsbl.sorbs.net]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
                             [209.85.213.47 listed in wl.mailspike.net]
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail provider
                             (philippe.vaucher[at]gmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid

>> My idea is pretty simple: just output the objects as a C file, then
>> compile and link the file.
>
> So we will be giving up the ability of end-users to re-dump their
> Emacs, unless they have a compiler/binutils installed that are
> compatible with the ones used to build the Emacs binary?

I doubt many end-users are aware of this feature, let alone use it.

IMHO, a saner compile cycle & the ability to play nice with modern
systems (ASLR, containers) largely outweights the loss of this
feature.

Philippe




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 17:41:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 06 13:41:27 2016
Received: from localhost ([127.0.0.1]:51646 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhKNA-000745-D1
	for submit <at> debbugs.gnu.org; Tue, 06 Sep 2016 13:41:27 -0400
Received: from eggs.gnu.org ([208.118.235.92]:33393)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1bhKN5-00073n-5a
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 13:41:22 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1bhKMw-0003EE-5Z
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 13:41:14 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58195)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1bhKMw-0003Dq-2I; Tue, 06 Sep 2016 13:41:10 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4926
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1bhKMr-0004qx-So; Tue, 06 Sep 2016 13:41:08 -0400
Date: Tue, 06 Sep 2016 20:40:41 +0300
Message-Id: <834m5tapuu.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-reply-to: <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN> (message from
 Paul Eggert on Tue, 6 Sep 2016 10:21:15 -0700)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
 <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -6.1 (------)
X-Debbugs-Envelope-To: 23529
Cc: p.stephani2@HIDDEN, philippe.vaucher@HIDDEN, 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.1 (------)

> From: Paul Eggert <eggert@HIDDEN>
> Date: Tue, 6 Sep 2016 10:21:15 -0700
> Cc: 23529 <at> debbugs.gnu.org
> 
> My idea is pretty simple: just output the objects as a C file, then 
> compile and link the file.

So we will be giving up the ability of end-users to re-dump their
Emacs, unless they have a compiler/binutils installed that are
compatible with the ones used to build the Emacs binary?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 17:34:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 06 13:34:37 2016
Received: from localhost ([127.0.0.1]:51640 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhKGW-0006tk-3t
	for submit <at> debbugs.gnu.org; Tue, 06 Sep 2016 13:34:37 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:36054)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1bhKGQ-0006tP-Ia
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 13:34:31 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5B596160DFF;
 Tue,  6 Sep 2016 10:21:16 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id YUMKfSuD0y2e; Tue,  6 Sep 2016 10:21:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id A8E5B16111A;
 Tue,  6 Sep 2016 10:21:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id znsLFR87cvRi; Tue,  6 Sep 2016 10:21:15 -0700 (PDT)
Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 91123160DFF;
 Tue,  6 Sep 2016 10:21:15 -0700 (PDT)
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Philipp Stephani <p.stephani2@HIDDEN>,
 Philippe Vaucher <philippe.vaucher@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
 <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <02c57124-ef39-bc30-89ba-998986d070fc@HIDDEN>
Date: Tue, 6 Sep 2016 10:21:15 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.1 (-)
X-Debbugs-Envelope-To: 23529
Cc: 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.1 (-)

On 09/06/2016 02:22 AM, Philipp Stephani wrote:
>
> Did you (or somebody else) by chance started working on this?

Not since we last wrote, no.

My idea is pretty simple: just output the objects as a C file, then 
compile and link the file. It should be reasonably portable. But there 
are a lot of details.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 09:23:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 06 05:23:11 2016
Received: from localhost ([127.0.0.1]:50876 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bhCb1-0006sI-7d
	for submit <at> debbugs.gnu.org; Tue, 06 Sep 2016 05:23:11 -0400
Received: from mail-wm0-f48.google.com ([74.125.82.48]:37526)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1bhCay-0006s3-SL
 for 23529 <at> debbugs.gnu.org; Tue, 06 Sep 2016 05:23:09 -0400
Received: by mail-wm0-f48.google.com with SMTP id w12so80072306wmf.0
 for <23529 <at> debbugs.gnu.org>; Tue, 06 Sep 2016 02:23:08 -0700 (PDT)
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; bh=DpQWMfVG1TguGeTeb3KBngTaXaThHj8KIS5i7MwxOxE=;
 b=kYQwKen1m9D72FCFAcwjs8pyqZPn4RsscJf2HofumiEFnXojlWFA3xpDHX8xoOcuNO
 JIwRu1D+rXbpv9lkT8DpOERPJ3Ae6N9z6jignlm66Z9OteHWoN8C6IusvgbymwB/0g0d
 strWMwJfV8ShjIE37l539jxt5ECCznw+3rTWT37TBJZoWr1jXN7Jo+/XxDC9ewIHZNbO
 3bXR3gh4SluLJtw/70qAuav1Yz38pf0CQDoXOu88LCTGEmU+tV0kRz1N4Rpqd9M/+XqF
 PT2GKXwSRGoUN5kp+6MGH/VWTpp1nqrY3zYDsPJlOnVM1+wxCqXnyVdrTRLIgf2q9yJj
 HAxQ==
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;
 bh=DpQWMfVG1TguGeTeb3KBngTaXaThHj8KIS5i7MwxOxE=;
 b=P3LZNceOYdmj8ljwuHl9RMwW3NmurNA+mB/QhCCkCUmh8xrEEOyoG13pMi0+ozm/jb
 D2C8qQtgd+GJxVwiInVLOgyD+FsuIIHtD2IAw+SVtQXnpO0My9ASxAXUcS+sQsje2Wv7
 YPYJ+oy7zaziUFCn5kk4nvvvF3noIUEVV6rnpuSkX7lcyae5nStDt2/Kdp3S7kOZwR2v
 DConL6XMVvljh9eqObhVmloQ1RqCo0lFhoL6yEE3+W883pdoZ2VzUp7LCA10BMhbb2XE
 IswyPWPnxab0y3FTbstPfJ4YP5aIkC0bLv1TqAfS3p86pXVO8k2ww7u2N0J/sk1j4Vvr
 4XpQ==
X-Gm-Message-State: AE9vXwOalNV+z3/W08IuhZPpIqAtTYudOUul0jzSeM8A0/pijcUIPKBHhyQCn2vNMrGOQOAkzV0q/iLkOZ26bA==
X-Received: by 10.28.232.71 with SMTP id f68mr1760022wmh.55.1473153783152;
 Tue, 06 Sep 2016 02:23:03 -0700 (PDT)
MIME-Version: 1.0
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
 <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
In-Reply-To: <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Tue, 06 Sep 2016 09:22:52 +0000
Message-ID: <CAArVCkTrjwbS3JqxNt_hqwz2azJPDWu4VSwCuHm_eX_pZaWEVw@HIDDEN>
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
To: Paul Eggert <eggert@HIDDEN>,
 Philippe Vaucher <philippe.vaucher@HIDDEN>
Content-Type: multipart/alternative; boundary=001a1146a152f1c91e053bd35735
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Paul Eggert schrieb am Fr., 20. Mai 2016 um 19:54 Uhr: > On
 05/18/2016 01:44 AM, Philippe Vaucher wrote: > > About the dumping procedure, 
 do you mean there*is* a > > plan to alter it after Emacs 25 comes out? >
 > Although we have no specific plan, it's on my list of things to do. I >
 took a stab at it a while ago but was not happy with the way my draft > was
 headed. I will see if I can do better next time. > > > Did you (or somebody
 else) by chance started working on this? I think removing unexec should have
 highest priority once 25 is out; its assumptions become increasingly less
 valid on modern systems (ASLR, seccomp-bpf, ASan, containers...). [...] 
 Content analysis details:   (1.9 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 2.4 RCVD_IN_SORBS_SPAM     RBL: SORBS: sender is a spam source
 [74.125.82.48 listed in dnsbl.sorbs.net]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
 digit (p.stephani2[at]gmail.com)
 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
 (p.stephani2[at]gmail.com)
 -0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
 [74.125.82.48 listed in wl.mailspike.net]
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at http://www.dnswl.org/, low
 trust [74.125.82.48 listed in list.dnswl.org]
 0.0 HTML_MESSAGE           BODY: HTML included in message
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid
X-Debbugs-Envelope-To: 23529
Cc: 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Paul Eggert schrieb am Fr., 20. Mai 2016 um 19:54 Uhr: > On
    05/18/2016 01:44 AM, Philippe Vaucher wrote: > > About the dumping procedure,
    do you mean there*is* a > > plan to alter it after Emacs 25 comes out? >
   > Although we have no specific plan, it's on my list of things to do. I >
   took a stab at it a while ago but was not happy with the way my draft > was
    headed. I will see if I can do better next time. > > > Did you (or somebody
    else) by chance started working on this? I think removing unexec should have
    highest priority once 25 is out; its assumptions become increasingly less
    valid on modern systems (ASLR, seccomp-bpf, ASan, containers...). [...] 
 
 Content analysis details:   (1.9 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
                             [74.125.82.48 listed in wl.mailspike.net]
  2.4 RCVD_IN_SORBS_SPAM     RBL: SORBS: sender is a spam source
                             [74.125.82.48 listed in dnsbl.sorbs.net]
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at http://www.dnswl.org/, low
                             trust
                             [74.125.82.48 listed in list.dnswl.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
                             digit (p.stephani2[at]gmail.com)
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail provider
                             (p.stephani2[at]gmail.com)
  0.0 HTML_MESSAGE           BODY: HTML included in message
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
  0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid

--001a1146a152f1c91e053bd35735
Content-Type: text/plain; charset=UTF-8

Paul Eggert <eggert@HIDDEN> schrieb am Fr., 20. Mai 2016 um 19:54 Uhr:

> On 05/18/2016 01:44 AM, Philippe Vaucher wrote:
> > About the dumping procedure, do you mean there*is*  a
> > plan to alter it after Emacs 25 comes out?
>
> Although we have no specific plan, it's on my list of things to do. I
> took a stab at it a while ago but was not happy with the way my draft
> was headed. I will see if I can do better next time.
>
>
>
Did you (or somebody else) by chance started working on this? I think
removing unexec should have highest priority once 25 is out; its
assumptions become increasingly less valid on modern systems (ASLR,
seccomp-bpf, ASan, containers...).

--001a1146a152f1c91e053bd35735
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">Paul E=
ggert &lt;<a href=3D"mailto:eggert@HIDDEN">eggert@HIDDEN</a>&gt; =
schrieb am Fr., 20. Mai 2016 um 19:54=C2=A0Uhr:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">On 05/18/2016 01:44 AM, Philippe Vaucher wrote:<br>
&gt; About the dumping procedure, do you mean there*is*=C2=A0 a<br>
&gt; plan to alter it after Emacs 25 comes out?<br>
<br>
Although we have no specific plan, it&#39;s on my list of things to do. I<b=
r>
took a stab at it a while ago but was not happy with the way my draft<br>
was headed. I will see if I can do better next time.<br>
<br><br></blockquote><div><br></div><div>Did you (or somebody else) by chan=
ce started working on this? I think removing unexec should have highest pri=
ority once 25 is out; its assumptions become increasingly less valid on mod=
ern systems (ASLR, seccomp-bpf, ASan, containers...).</div></div></div>

--001a1146a152f1c91e053bd35735--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.
Removed tag(s) moreinfo. Request was from Glenn Morris <rgm@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 20 May 2016 17:53:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 20 13:53:05 2016
Received: from localhost ([127.0.0.1]:59307 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1b3obh-0006Z0-Gz
	for submit <at> debbugs.gnu.org; Fri, 20 May 2016 13:53:05 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:48495)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1b3obf-0006YW-8Y
 for 23529 <at> debbugs.gnu.org; Fri, 20 May 2016 13:53:03 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5EF64161326;
 Fri, 20 May 2016 10:52:56 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id L9nETa9dbFRI; Fri, 20 May 2016 10:52:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id B23F416132A;
 Fri, 20 May 2016 10:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id X646vkoVE4qc; Fri, 20 May 2016 10:52:55 -0700 (PDT)
Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 98B0B161326;
 Fri, 20 May 2016 10:52:55 -0700 (PDT)
Subject: Re: Request for fixing randomize_va_space build issues
To: Philippe Vaucher <philippe.vaucher@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
 <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <54b89449-083a-a906-986a-f284dbbf482a@HIDDEN>
Date: Fri, 20 May 2016 10:52:55 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.4 (-)
X-Debbugs-Envelope-To: 23529
Cc: 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.4 (-)

On 05/18/2016 01:44 AM, Philippe Vaucher wrote:
> About the dumping procedure, do you mean there*is*  a
> plan to alter it after Emacs 25 comes out?

Although we have no specific plan, it's on my list of things to do. I 
took a stab at it a while ago but was not happy with the way my draft 
was headed. I will see if I can do better next time.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 18 May 2016 08:45:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 18 04:45:15 2016
Received: from localhost ([127.0.0.1]:56525 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1b2x6R-00009s-D5
	for submit <at> debbugs.gnu.org; Wed, 18 May 2016 04:45:15 -0400
Received: from mail-vk0-f67.google.com ([209.85.213.67]:35820)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philippe.vaucher@HIDDEN>) id 1b2x6P-00009e-F7
 for 23529 <at> debbugs.gnu.org; Wed, 18 May 2016 04:45:13 -0400
Received: by mail-vk0-f67.google.com with SMTP id e126so5993253vkb.2
 for <23529 <at> debbugs.gnu.org>; Wed, 18 May 2016 01:45:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to
 :cc; bh=Nz+xWn9A3144UyFRoaxKCIzE3cxJXl1Wp3bdi0ibxvw=;
 b=ONQY9fvnuO/76j5obAjDVQwbvXcYD0ni5+iiI8xJEFYk5Sqsf/h+YoRP1fsNj3xNR3
 0YS8Td/VqECtUtQSAQbvj0d+BkmTrDaGkDAs2jg2R5X1P4bjdu0z1GN1q3soIZZbsVV7
 uzajt8Q+epKRC5Ew35UITVLkWUUV9FSBGVQA3KcABWti9Dr2TJRSrWvZMXV8KlLsSZCU
 ES/EyO02uMijiM7LwCzuPfVPY+aJGef5CEPbEhLXJxTG4gj+aGkFNQBTX/uUuM5guLnd
 eVY/w/wSXGNnqlxrKEruU8Bm9PJGjvChnSTHjazb5xYQkbpCgRmCy92dJKf6mCKWbb3N
 KYyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:in-reply-to:references:from:date
 :message-id:subject:to:cc;
 bh=Nz+xWn9A3144UyFRoaxKCIzE3cxJXl1Wp3bdi0ibxvw=;
 b=jIJpkAXTxe2ywSlrtbbBMFgVO/Tw5mUVrCeuSD1R0ImBlbCju6CHoG+bi8D8xiJnTA
 iRBPYgvs6C7g+HBG2Xw+m2vxh1/SXB687AwXiQirNObVQuBk86f5iza/S0dIz6VPpAuw
 ATaDvTdtxm6GjJQA4KS9B5ueYdOC+yh4Ew25jLPLgqFHuw8UsXZsUSDUnjgEYA0h/sIb
 VIBXVYswJU3NHt5ZuCB9qIU9ldRDglD4I7fwanYEAq9LUqksX1yVcmoliwJbs1Q9lZ7Y
 JbWTMCP1HqArCBKAF369QpeZaBbDacDOWZqeXVCdmFo5Ln31rpwTt/y/OnqSmSeZIBi6
 aIqg==
X-Gm-Message-State: AOPr4FUUu/k2cmnMbhtORdRFZYLvI1OtR/MqZkT0C9StBagY0o8gRA/g3ytuYcR/YwnH1OpOHyuIT1UPd9624Q==
X-Received: by 10.159.38.72 with SMTP id 66mr2399594uag.126.1463561107331;
 Wed, 18 May 2016 01:45:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.28.133 with HTTP; Wed, 18 May 2016 01:44:37 -0700 (PDT)
In-Reply-To: <573C2601.3030308@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
 <573C2601.3030308@HIDDEN>
From: Philippe Vaucher <philippe.vaucher@HIDDEN>
Date: Wed, 18 May 2016 10:44:37 +0200
Message-ID: <CAGK7Mr77fanGCxd1UuaKO19buq7XYCPDWvXaY=oGo+MmAW5mkg@HIDDEN>
Subject: Re: Request for fixing randomize_va_space build issues
To: Paul Eggert <eggert@HIDDEN>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 23529
Cc: 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

> Some background: Emacs has an 'undump' function that saves the Emacs state as an
> executable: when you run the executable, you get an Emacs with the same (or
> nearly the same) state. This makes Emacs startup considerably faster. Objects in
> the restored state must be in the same location as when they were saved, so the
> executable cannot be subject to ASLR.

Alright, that makes sense now.

> I don't know all the ins and outs of why it is necessary for Emacs to invoke
> 'personality'. As I understand it, the build procedure should invoke the shell
> command 'setfattr -n user.pax.flags -v er temacs' immediately after building
> temacs, and I don't know why this doesn't make the 'personality' call
> unnecessary. Perhaps you can consult a seccomp expert who can tell you what's
> going on, as seccomp is not well-documented. If there is some way to disable
> ASLR without calling 'personality', that should fix your problem.

I'll try to debug the `setfattr` part to see what it does. I seems
that `setarch -R` and `personality` both "works" return-status wise
but in practice inside docker they don't change anything (and thus
don't disable ASLR). It looks like eventually the problem will be
fixed on the docker side... but maybe the debug session will yield
some emacs patch.

> Regardless, the advice in etc/PROBLEMS is clearly obsolete here, so I installed
> the attached patch to try to make things clearer. We're not going to greatly
> alter the dumping procedure before Emacs 25 comes out (it's too late in the
> release process) but we should do better in the future. For now we should at
> least document the issues better.

Ah, good patch! About the dumping procedure, do you mean there *is* a
plan to alter it after Emacs 25 comes out? The building behavior on
this issue about ASLR between 24.5 and 25.0.93 seems very similar from
my experience.

>> I tried to run "./temacs --batch --load loadup bootstrap" inside GDB
>> to get more insights about why it segfaults there, but somehow gdb
>> fails to catch it. Maybe because of spawned processes?
>
> Yes, the code you highlighted does an execvp. You might try fiddling with GDB's
> follow-exec-mode variable; see
> <https://sourceware.org/gdb/onlinedocs/gdb/Forks.html>.

I'll play with it. Thanks!
Philippe




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 18 May 2016 08:21:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 18 04:21:39 2016
Received: from localhost ([127.0.0.1]:56520 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1b2wjW-00083X-0W
	for submit <at> debbugs.gnu.org; Wed, 18 May 2016 04:21:39 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:45561)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1b2wjU-00083I-7o
 for 23529 <at> debbugs.gnu.org; Wed, 18 May 2016 04:21:33 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9A5B91601C0;
 Wed, 18 May 2016 01:21:23 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id 88a1VaAS1N1x; Wed, 18 May 2016 01:21:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 195E41610C4;
 Wed, 18 May 2016 01:21:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id h6hnoBBMIk7r; Wed, 18 May 2016 01:21:22 -0700 (PDT)
Received: from [192.168.1.9] (unknown [100.32.155.148])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id ED4FB1601C0;
 Wed, 18 May 2016 01:21:21 -0700 (PDT)
From: Paul Eggert <eggert@HIDDEN>
Subject: Re: Request for fixing randomize_va_space build issues
To: Philippe Vaucher <philippe.vaucher@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <573C2601.3030308@HIDDEN>
Date: Wed, 18 May 2016 01:21:21 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
Content-Type: multipart/mixed; boundary="------------080307040907070706050206"
X-Spam-Score: -1.4 (-)
X-Debbugs-Envelope-To: 23529
Cc: 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.4 (-)

This is a multi-part message in MIME format.
--------------080307040907070706050206
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Some background: Emacs has an 'undump' function that saves the Emacs stat=
e as an
executable: when you run the executable, you get an Emacs with the same (=
or
nearly the same) state. This makes Emacs startup considerably faster. Obj=
ects in
the restored state must be in the same location as when they were saved, =
so the
executable cannot be subject to ASLR.

On 05/17/2016 09:38 AM, Philippe Vaucher wrote:

> Some information about why the personality syscall is disabled in my en=
v:
>
> https://github.com/docker/docker/blob/master/docs/security/seccomp.md
>

That says the 'personality' syscall is "Not inherently dangerous, but poo=
rly
tested". Although this justifies paranoia in some applications, we are ta=
lking
*Emacs* here. (People worried about poorly tested code should not be runn=
ing
Emacs. :-) So a simple way to fix the problem, as I guess you've discover=
ed, is
to allow the 'personality' syscall in your Docker image.

I don't know all the ins and outs of why it is necessary for Emacs to inv=
oke
'personality'. As I understand it, the build procedure should invoke the =
shell
command 'setfattr -n user.pax.flags -v er temacs' immediately after build=
ing
temacs, and I don't know why this doesn't make the 'personality' call
unnecessary. Perhaps you can consult a seccomp expert who can tell you wh=
at's
going on, as seccomp is not well-documented. If there is some way to disa=
ble
ASLR without calling 'personality', that should fix your problem.

Regardless, the advice in etc/PROBLEMS is clearly obsolete here, so I ins=
talled
the attached patch to try to make things clearer. We're not going to grea=
tly
alter the dumping procedure before Emacs 25 comes out (it's too late in t=
he
release process) but we should do better in the future. For now we should=
 at
least document the issues better.

> I tried to run "./temacs --batch --load loadup bootstrap" inside GDB
> to get more insights about why it segfaults there, but somehow gdb
> fails to catch it. Maybe because of spawned processes?

Yes, the code you highlighted does an execvp. You might try fiddling with=
 GDB's
follow-exec-mode variable; see
<https://sourceware.org/gdb/onlinedocs/gdb/Forks.html>.


--------------080307040907070706050206
Content-Type: text/x-diff;
 name="0001-Modernize-ASLR-advice-in-etc-PROBLEMS.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0001-Modernize-ASLR-advice-in-etc-PROBLEMS.patch"

=46rom b412bcd921b4dd788c17f9077f02d1d592ea7e0a Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@HIDDEN>
Date: Wed, 18 May 2016 01:05:00 -0700
Subject: [PATCH] Modernize ASLR advice in etc/PROBLEMS

* etc/PROBLEMS (Segfault during 'make'): Modernize advice for
seccomp, Docker, and NetBSD (Bug#23529).
---
 etc/PROBLEMS | 77 +++++++++++++++++++++++++++++++++++++-----------------=
------
 1 file changed, 48 insertions(+), 29 deletions(-)

diff --git a/etc/PROBLEMS b/etc/PROBLEMS
index 533c4e9..8733095 100644
--- a/etc/PROBLEMS
+++ b/etc/PROBLEMS
@@ -2600,51 +2600,70 @@ See <URL:http://debbugs.gnu.org/327>, <URL:http:/=
/debbugs.gnu.org/821>.
=20
 ** Dumping
=20
-*** Segfault during 'make bootstrap' under the Linux kernel.
+*** Segfault during 'make'
=20
-In Red Hat Linux kernels, "Exec-shield" functionality is enabled by
-default, which creates a different memory layout that can break the
-emacs dumper.  Emacs tries to handle this at build time, but if this
-fails, the following instructions may be useful.
+If Emacs segfaults when 'make' executes one of these commands:
=20
-Exec-shield is enabled on your system if
+  LC_ALL=3DC ./temacs -batch -l loadup bootstrap
+  LC_ALL=3DC ./temacs -batch -l loadup dump
=20
-    cat /proc/sys/kernel/exec-shield
+the problem may be due to inadequate workarounds for address space
+layout randomization (ASLR), an operating system feature that
+randomizes the virtual address space of a process.  ASLR is commonly
+enabled in Linux and NetBSD kernels, and is intended to deter exploits
+of pointer-related bugs in applications.  If ASLR is enabled, the
+command:
=20
-prints a value other than 0.  (Please read your system documentation
-for more details on Exec-shield and associated commands.)
+   cat /proc/sys/kernel/randomize_va_space  # GNU/Linux
+   sysctl security.pax.aslr.global          # NetBSD
=20
-Additionally, Linux kernel versions since 2.6.12 randomize the virtual
-address space of a process by default.  If this feature is enabled on
-your system, then
+outputs a nonzero value.
=20
-   cat /proc/sys/kernel/randomize_va_space
+These segfaults should not occur on most modern systems, because the
+Emacs build procedure uses the command 'setfattr' or 'paxctl' to mark
+the Emacs executable as requiring non-randomized address space, and
+Emacs uses the 'personality' system call to disable address space
+randomization when dumping.  However, older kernels may not support
+'setfattr', 'paxctl', or 'personality', and newer Linux kernels have a
+secure computing mode (seccomp) that can be configured to disable the
+'personality' call.
=20
-prints a value other than 0.
+It may be possible to work around the 'personality' problem in a newer
+Linux kernel by configuring seccomp to allow the 'personality' call.
+For example, if you are building Emacs under Docker, you can run the
+Docker container with a security profile that allows 'personality' by
+using Docker's --security-opt option with an appropriate profile; see
+<https://docs.docker.com/engine/security/seccomp/>.
=20
-When these features are enabled, building Emacs may segfault during
-the execution of this command:
+To work around the ASLR problem in either an older or a newer kernel,
+you can temporarily disable the feature while building Emacs.  On
+GNU/Linux you can do so using the following command (as root).
=20
-    ./temacs --batch --load loadup [dump|bootstrap]
+    echo 0 > /proc/sys/kernel/randomize_va_space
=20
-To work around this problem, you can temporarily disable these
-features while building Emacs.  You can do so using the following
-commands (as root).  Remember to re-enable them when you are done,
-by echoing the original values back to the files.
+You can re-enable the feature when you are done, by echoing the
+original value back to the file.  NetBSD uses a different command,
+e.g., 'sysctl -w security.pax.aslr.global=3D0'.
=20
-    echo 0 > /proc/sys/kernel/exec-shield
-    echo 0 > /proc/sys/kernel/randomize_va_space
+Alternatively, you can try using the 'setarch' command when building
+temacs like this, where -R disables address space randomization:
=20
-Or, on x86, you can try using the 'setarch' command when running
-temacs, like this:
+    setarch $(uname -m) -R make
=20
-    setarch i386 -R ./temacs --batch --load loadup [dump|bootstrap]
+ASLR is not the only problem that can break Emacs dumping.  Another
+issue is that in Red Hat Linux kernels, Exec-shield is enabled by
+default, and this creates a different memory layout.  Emacs should
+handle this at build time, but if this fails the following
+instructions may be useful.  Exec-shield is enabled on your system if
=20
-or
+    cat /proc/sys/kernel/exec-shield
+
+prints a nonzero value.  You can temporarily disable it as follows:
=20
-    setarch i386 -R make
+    echo 0 > /proc/sys/kernel/exec-shield
=20
-(The -R option disables address space randomization.)
+As with randomize_va_space, you can re-enable Exec-shield when you are
+done, by echoing the original value back to the file.
=20
 *** temacs prints "Pure Lisp storage exhausted".
=20
--=20
2.5.5


--------------080307040907070706050206--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 18 May 2016 07:54:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 18 03:54:29 2016
Received: from localhost ([127.0.0.1]:56497 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1b2wJJ-0007On-K0
	for submit <at> debbugs.gnu.org; Wed, 18 May 2016 03:54:29 -0400
Received: from mail-vk0-f42.google.com ([209.85.213.42]:33266)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philippe.vaucher@HIDDEN>) id 1b2wJH-0007Oa-VM
 for 23529 <at> debbugs.gnu.org; Wed, 18 May 2016 03:54:28 -0400
Received: by mail-vk0-f42.google.com with SMTP id z184so51117895vkg.0
 for <23529 <at> debbugs.gnu.org>; Wed, 18 May 2016 00:54:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to
 :cc; bh=iIqoDe1J+NrMdiqCFUm28rN9103HrXzlBfFoPT43j78=;
 b=fChN7/KU4yEEkLwBWOBg/547SBWVE2aAuZIdqhph2A7/g2IXU2a6TMFF6MpdG2IYJh
 km4o4/EM+md1SqG2GmqGj3XcDvP9ZhmLksS/v329PGa6Q42GAQnS3MkZlngOuMfjvL6H
 f043a9b8rZHqhsGr96ysv/lx8siZSVG8Di6uoRCHPw/J0q6nNGdiuuSpH3XA9S9cn6aO
 +dTaYYnC+S8GfC1jbLqeOY+vr8dH6mvu8QM3uPR50cFIIqB7bEImOJMRl6ROHSPWIXF2
 6odBtC131y+go3QPGmyOsQvOrYN6OZMXXaFRt95+omN52ZqBvDofGq2gJAyPbA9Rg6Zi
 oWAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:in-reply-to:references:from:date
 :message-id:subject:to:cc;
 bh=iIqoDe1J+NrMdiqCFUm28rN9103HrXzlBfFoPT43j78=;
 b=JIRoktzCNA+6J5qCD1lMzd+HzooHbPPVpPxmIO+uN8t74TGO6VMkIoM7mQrhqOhaCg
 HCa1Q/+cJtoSHbm6qWWJPLiKKeptO8YydY9w6fjrpy47BlmNibZ38X8tsViyEBGJVZCE
 mCxkAJamfcysh/rIwLSfJ8ZabQ6ehj+1IuiG9B5v6wDw7nazHy1+Lg6ZaIq5UsjLVbKC
 wOR+jEOPSz7QtV5t+ZMMPzQrCNGqXx5GsDjbC2Bpvj7pFPKY8K9QuJ/cGiIF7EZaFKww
 SZzYj6Wt/y2j43RvWK0FnQZfF26nudZtekVyKZMEWZmlkLLwCCmKddU0MF/DMtVxHH8T
 RxTQ==
X-Gm-Message-State: AOPr4FVCcb3/EIfp5pHJGN0SaHmKp8Pu+xzuXfwZk7hHZ+39/W3nmekIeA2lxSvbXMZ/uvN5q9Q95FGdrYGBQQ==
X-Received: by 10.176.7.67 with SMTP id h61mr3280909uah.55.1463558062366; Wed,
 18 May 2016 00:54:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.28.133 with HTTP; Wed, 18 May 2016 00:53:52 -0700 (PDT)
In-Reply-To: <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
 <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
From: Philippe Vaucher <philippe.vaucher@HIDDEN>
Date: Wed, 18 May 2016 09:53:52 +0200
Message-ID: <CAGK7Mr4_HnFndYne6aiaYgkQAS6orMxvVzDCzM9xXgsSMMbkzA@HIDDEN>
Subject: Re: Request for fixing randomize_va_space build issues
To: Paul Eggert <eggert@HIDDEN>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 23529
Cc: 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

> Yes, because when building emacs it calls ./temacs which calls
> "personality" like here
> https://github.com/emacs-mirror/emacs/blob/master/src/emacs.c#L802-819
> This basically does the same as disabling randomize_va_space.

For information, I also opened an issue with docker because it might
be an ubuntu:16.04/seccomp issue
https://github.com/docker/docker/issues/22801

I'll keep you posted, but it's interesting that emacs needs
`personality` syscalls in order to build. I'm curious about why there
is this somewhat intermediate "temacs" binary that seems to have the
ability to dump itself into the final binary.

Philippe




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 17 May 2016 16:38:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 17 12:38:45 2016
Received: from localhost ([127.0.0.1]:56170 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1b2i17-0002Nx-5b
	for submit <at> debbugs.gnu.org; Tue, 17 May 2016 12:38:45 -0400
Received: from mail-vk0-f52.google.com ([209.85.213.52]:33021)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philippe.vaucher@HIDDEN>) id 1b2i14-0002Nj-Ci
 for 23529 <at> debbugs.gnu.org; Tue, 17 May 2016 12:38:44 -0400
Received: by mail-vk0-f52.google.com with SMTP id z184so27317733vkg.0
 for <23529 <at> debbugs.gnu.org>; Tue, 17 May 2016 09:38:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to
 :cc; bh=GUaDjy7sOIls0zeHlIK67nuZD8okQzGmo7hOVUq0mfY=;
 b=mPiFQ48t+lJo3N+0Z2ZNJYy2F0bLa2rn9LUJ9EqCJwp017mKEf0mVBSEsqrC9q3BrK
 6BpFmZuM0ehOm6LhD7smO0KwabRoxQDdeEffJgF7f5YnOzWHvggCtRvIQ+Jf8oDtn6cH
 g3vEfuPfWJgB/YllevJS+zQ6GBpgJ6Ll2qXfLb6L/EK5jTiDpojd20JXN43S3amez7Sq
 SEd2BW1fU1FGVWTZyD1c2OPh88jmBudk5MwvXUbBELNtB9zyF0xijGZyQLdUYZa3QxkQ
 gxdxpiOzczx0rwuadDZSMBUHWayu/nZoPcX0JnloITyezGotSx84g/luQpNC0VMEOop7
 HSUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:in-reply-to:references:from:date
 :message-id:subject:to:cc;
 bh=GUaDjy7sOIls0zeHlIK67nuZD8okQzGmo7hOVUq0mfY=;
 b=GFz2VNIwOjwq+e6xJJYJpnejDGLn56UvY3JuPqGCoHU8IHdJNc5O27hMSyHOlGI9xt
 1NgSnoylQRN/Y2Rz2ktxg3mmi1aMMZzOb3F+b/TXyltz28woViXXvFC1uLJjCym1jfPN
 ChbCKadmdpYwBmdyd7wcQc70+YfTsmrNrCsLz8RegLObAoBjNGLj2phAY/VR6Cc1bzeX
 1+TrOPtnrnEps4M03Jl9BlvRy8BAWBj6xRX5wZNINwI6G+painm4i3CDU4+g7gpD9mk/
 7Fz/EOCinoxiC4d9CBONvvajgv5OJdX8bV8VcCPnoh+D4IJWfx4c8xxICb4891aUXN/K
 SR6Q==
X-Gm-Message-State: AOPr4FXH+Dgbvg9Mc+yWLcSexFR7lhBCGq7YOXRE/MoDRBHgsiEjhKBvGTxwCXXTIG1CYxrBCIxYhZZvwsXvTw==
X-Received: by 10.31.171.69 with SMTP id u66mr1206421vke.119.1463503116794;
 Tue, 17 May 2016 09:38:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.28.133 with HTTP; Tue, 17 May 2016 09:38:07 -0700 (PDT)
In-Reply-To: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
References: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
From: Philippe Vaucher <philippe.vaucher@HIDDEN>
Date: Tue, 17 May 2016 18:38:07 +0200
Message-ID: <CAGK7Mr6pAwd4zM-BEc=0oSOkE7nkdTpnfkOP7bF99hjJsSPnjg@HIDDEN>
Subject: Re: Request for fixing randomize_va_space build issues
To: Paul Eggert <eggert@HIDDEN>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 23529
Cc: 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

On Fri, May 13, 2016 at 5:58 PM, Paul Eggert <eggert@HIDDEN> wrote:
> I am not observing the problem on Fedora 23 x86-64, even though
> /proc/sys/kernel/randomize_va_space is 2 on my platform.

Yes, because when building emacs it calls ./temacs which calls
"personality" like here
https://github.com/emacs-mirror/emacs/blob/master/src/emacs.c#L802-819
This basically does the same as disabling randomize_va_space.

Disallow the syscall to personality and you'll see emacs segfaults
while building.

Some information about why the personality syscall is disabled in my env:

https://github.com/docker/docker/blob/master/docs/security/seccomp.md

> Emacs has had bug fixes in this area. You don't mention which version of
> Emacs you're using, or which platform. I suggest trying the latest test
> version of Emacs, and if this doesn't work then please send details about
> your platform and how you configured and built Emacs.

I'm building on Ubuntu 16.04 Linux 4.4.0-22-generic x86_64 GNU/Linux
with Docker 1.11.1.

I tried to run "./temacs --batch --load loadup bootstrap" inside GDB
to get more insights about why it segfaults there, but somehow gdb
fails to catch it. Maybe because of spawned processes?

I run gdb like this: "gdb --args ./temacs --batch --load loadup
bootstrap" followed by "run"

I also tried to disable personalities alltogether by undefined
HAVE_PERSONALITY_LINUX32 but the only way I found was to mess with the
./configure detection... I'll investiguate. If you have any tricks to
have emacs be more verbose about its segfault it'd be appreciated.

Thanks,
Philippe




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.
Added tag(s) moreinfo. Request was from Paul Eggert <eggert@HIDDEN> to control <at> debbugs.gnu.org. Full text available.
Forcibly Merged 13964 23529. Request was from Glenn Morris <rgm@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Message received at 23529 <at> debbugs.gnu.org:


Received: (at 23529) by debbugs.gnu.org; 13 May 2016 15:58:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 13 11:58:58 2016
Received: from localhost ([127.0.0.1]:50127 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1b1FUQ-0006Wx-JZ
	for submit <at> debbugs.gnu.org; Fri, 13 May 2016 11:58:58 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:43432)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1b1FUO-0006Wg-Js
 for 23529 <at> debbugs.gnu.org; Fri, 13 May 2016 11:58:57 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 971401612A2;
 Fri, 13 May 2016 08:58:50 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id aO5cqgBgdayH; Fri, 13 May 2016 08:58:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id C23AC1612A6;
 Fri, 13 May 2016 08:58:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id BShsWEMALSL6; Fri, 13 May 2016 08:58:49 -0700 (PDT)
Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id AB8851612A2;
 Fri, 13 May 2016 08:58:49 -0700 (PDT)
To: Philippe Vaucher <philippe.vaucher@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Subject: Re: Request for fixing randomize_va_space build issues
Organization: UCLA Computer Science Department
Message-ID: <f8d4b6a0-c7a3-c6ff-0faf-577c2aa69809@HIDDEN>
Date: Fri, 13 May 2016 08:58:46 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.4 (-)
X-Debbugs-Envelope-To: 23529
Cc: 23529 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.4 (-)

I am not observing the problem on Fedora 23 x86-64, even though 
/proc/sys/kernel/randomize_va_space is 2 on my platform.

Emacs has had bug fixes in this area. You don't mention which version of 
Emacs you're using, or which platform. I suggest trying the latest test 
version of Emacs, and if this doesn't work then please send details 
about your platform and how you configured and built Emacs.

ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-25.0.93.tar.xz





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 13 May 2016 12:19:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 13 08:19:36 2016
Received: from localhost ([127.0.0.1]:49632 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1b1C47-0001C6-UG
	for submit <at> debbugs.gnu.org; Fri, 13 May 2016 08:19:36 -0400
Received: from eggs.gnu.org ([208.118.235.92]:45680)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philippe.vaucher@HIDDEN>) id 1b1C45-0001Bs-W5
 for submit <at> debbugs.gnu.org; Fri, 13 May 2016 08:19:34 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <philippe.vaucher@HIDDEN>) id 1b1C3z-0003mA-Cv
 for submit <at> debbugs.gnu.org; Fri, 13 May 2016 08:19:28 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM,
 T_DKIM_INVALID autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:42704)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <philippe.vaucher@HIDDEN>) id 1b1C3z-0003m4-9d
 for submit <at> debbugs.gnu.org; Fri, 13 May 2016 08:19:27 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:36641)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <philippe.vaucher@HIDDEN>) id 1b1C3w-00022d-Pp
 for bug-gnu-emacs@HIDDEN; Fri, 13 May 2016 08:19:26 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <philippe.vaucher@HIDDEN>) id 1b1C3v-0003lh-AA
 for bug-gnu-emacs@HIDDEN; Fri, 13 May 2016 08:19:24 -0400
Received: from mail-vk0-x243.google.com ([2607:f8b0:400c:c05::243]:35428)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <philippe.vaucher@HIDDEN>) id 1b1C3v-0003lZ-2v
 for bug-gnu-emacs@HIDDEN; Fri, 13 May 2016 08:19:23 -0400
Received: by mail-vk0-x243.google.com with SMTP id m188so11894595vka.2
 for <bug-gnu-emacs@HIDDEN>; Fri, 13 May 2016 05:19:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:from:date:message-id:subject:to;
 bh=AnXlNNMjJc0wtEYGj9OQY5h9kPXHJFXZt+QptelLdm4=;
 b=NGuX6RC3OqgoBLm+qnMrqBrLcjZ3V5Xkr9PvRFp5ii7LgY37W3SFGwiu7zqlMwbBwl
 c1e+JqPq1mWziUEWakn3jmPNENABpukDKgl+imxRRaOseb98zDEeZfcKM4im2ntD+XR7
 7aCCzQ/PPrif/eVld7RW5leFcIBemxfaCEV0YAj2/Q14pIqvJQ1RxJ8P/SSBHGPAIwpt
 PbDU09P1eoZGFY1Vrxd8CLufD8oNNqvZM+rXl0J8qQJrP+S0iIacE3rBWzsRzhYzY8Ww
 xrNmj2gJ5S24oOFRPVijzFQvGlnI5CEt2qBDxRH+HnIhNMZuXW7Ql7BySbs26wtUPOTj
 V1hA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=AnXlNNMjJc0wtEYGj9OQY5h9kPXHJFXZt+QptelLdm4=;
 b=SiU8WCQE7k1vkXS6CTg5ApsIW/0pBwyZ3ficXxSQ2F1h6T69Q+k/QcwN776o8r7ygK
 OqIF1nOw5rMH05MKF19AG6jn2K3lejY+JRZe4Fbu1CvS2NvMtQ938NMHLVrcscHYwro/
 dRpHlE8+SS2bG8qUhBUtAyVZINzYfUufCIKciL1sU7lKKfnHSHco1mjhAYRHTFxx5Dko
 CDzR1ebVscJGCCrWfNZOTQI2EssNo8GIwhwvjFLNSy5UStXN0oRe4vIE9ZLQKXB/gCfx
 Z4eNQZ/jTp7ohxOK8Ql3guqSIe6N99ELhyMZnm2Dhi+IeEMcfuK9S1PmZEeZqzcAdPqV
 kuIw==
X-Gm-Message-State: AOPr4FVcm3osECrr0vPzeustWdbrAnwClCZQzUld2Vf99m8Lpn3MJ8eNgp79SF+q19DdEinN/RCbW+K9eYrKeg==
X-Received: by 10.31.179.13 with SMTP id c13mr7089105vkf.18.1463141962069;
 Fri, 13 May 2016 05:19:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.28.133 with HTTP; Fri, 13 May 2016 05:18:52 -0700 (PDT)
From: Philippe Vaucher <philippe.vaucher@HIDDEN>
Date: Fri, 13 May 2016 14:18:52 +0200
Message-ID: <CAGK7Mr5G5me5B_6EHfWSQ+zS=BskyC-9wocPnnAFU-RYo8T0SA@HIDDEN>
Subject: Request for fixing randomize_va_space build issues
To: bug-gnu-emacs@HIDDEN
Content-Type: text/plain; charset=UTF-8
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -4.0 (----)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.0 (----)

Hello,

When /proc/sys/kernel/randomize_va_space is 2, emacs fails to build:

    Dumping under the name emacs
    **************************************************
    Warning: Your system has a gap between BSS and the
    heap (20865783 bytes).  This usually means that exec-shield
    or something similar is in effect.  The dump may
    fail because of this.  See the section about
    exec-shield in etc/PROBLEMS for more information.
    **************************************************
    /bin/bash: line 7:  8981 Segmentation fault      (core dumped)
./temacs --batch --load loadup bootstrap
    Makefile:815: recipe for target 'bootstrap-emacs' failed
    make[1]: *** [bootstrap-emacs] Error 1
    make[1]: Leaving directory '/tmp/emacs/src'

This is a somewhat known bug:

https://debbugs.gnu.org/db/13/13964.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598234
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566947
https://bugzilla.redhat.com/show_bug.cgi?id=160814

I know there is a workaround that goes like:

    echo 0 > /proc/sys/kernel/randomize_va_space
    make
    echo 2 > /proc/sys/kernel/randomize_va_space

But in my case this is not possible, I'm building as a user with
limited privileges.

The file /etc/PROBLEMS mention another workaround:

    setarch x86_64 -R make

But this fails with the same error.

I'm far from being the only one with this problem:

https://github.com/boot2docker/boot2docker/issues/1136
https://github.com/ensime/ensime-emacs/issues/369
https://github.com/proot-me/PRoot/issues/52

And basically the workaround is always "set randomize_va_space to 0".

Can someone explain what the real issue is and what we could do to
_really_ fix it? One should be able to compile emacs without changing
kernel parameters!

Thanks in advance,
Philippe




Acknowledgement sent to Philippe Vaucher <philippe.vaucher@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#23529; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Sun, 11 Sep 2016 17:30:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.