From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Philippe Vaucher Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 May 2016 12:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 23529@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.14631419764598 (code B ref -1); Fri, 13 May 2016 12:20:02 +0000 Received: (at submit) by debbugs.gnu.org; 13 May 2016 12:19:36 +0000 Received: from localhost ([127.0.0.1]:49632 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b1C47-0001C6-UG for submit@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 ) id 1b1C45-0001Bs-W5 for submit@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 ) id 1b1C3z-0003mA-Cv for submit@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 ) id 1b1C3z-0003m4-9d for submit@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 ) id 1b1C3w-00022d-Pp for bug-gnu-emacs@gnu.org; Fri, 13 May 2016 08:19:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b1C3v-0003lh-AA for bug-gnu-emacs@gnu.org; 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 ) id 1b1C3v-0003lZ-2v for bug-gnu-emacs@gnu.org; Fri, 13 May 2016 08:19:23 -0400 Received: by mail-vk0-x243.google.com with SMTP id m188so11894595vka.2 for ; 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 Date: Fri, 13 May 2016 14:18:52 +0200 Message-ID: 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues References: In-Reply-To: Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 May 2016 15:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philippe Vaucher Cc: 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.146315513825111 (code B ref 23529); Fri, 13 May 2016 15:59:02 +0000 Received: (at 23529) by debbugs.gnu.org; 13 May 2016 15:58:58 +0000 Received: from localhost ([127.0.0.1]:50127 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b1FUQ-0006Wx-JZ for submit@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 ) id 1b1FUO-0006Wg-Js for 23529@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) From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Fri May 13 12:38:11 2016 Received: (at control) by debbugs.gnu.org; 13 May 2016 16:38:11 +0000 Received: from localhost ([127.0.0.1]:50154 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b1G6N-0007Zs-6K for submit@debbugs.gnu.org; Fri, 13 May 2016 12:38:11 -0400 Received: from eggs.gnu.org ([208.118.235.92]:44289) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b1G6L-0007Zg-Mv for control@debbugs.gnu.org; Fri, 13 May 2016 12:38:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b1G6F-0007IQ-Jx for control@debbugs.gnu.org; Fri, 13 May 2016 12:38: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=-3.3 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]:40597) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b1G6F-0007Hs-I5 for control@debbugs.gnu.org; Fri, 13 May 2016 12:38:03 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1b1G6E-0007Lz-52 for control@debbugs.gnu.org; Fri, 13 May 2016 12:38:02 -0400 Subject: control message for bug 23529 To: X-Mailer: mail (GNU Mailutils 2.99.98) Message-Id: From: Glenn Morris Date: Fri, 13 May 2016 12:38:02 -0400 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.4 (------) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.4 (------) forcemerge 13964 23529 From debbugs-submit-bounces@debbugs.gnu.org Sat May 14 23:01:37 2016 Received: (at control) by debbugs.gnu.org; 15 May 2016 03:01:37 +0000 Received: from localhost ([127.0.0.1]:51901 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b1mJF-0002ce-46 for submit@debbugs.gnu.org; Sat, 14 May 2016 23:01:37 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:48023) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b1mJD-0002cP-H5 for control@debbugs.gnu.org; Sat, 14 May 2016 23:01:36 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 715F31612A4 for ; Sat, 14 May 2016 20: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 rzGasyeNwunJ for ; Sat, 14 May 2016 20:01:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B2A311612CA for ; Sat, 14 May 2016 20: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 h6T6IP3PX0-6 for ; Sat, 14 May 2016 20:01:28 -0700 (PDT) Received: from [192.168.1.9] (unknown [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 996D01612A4 for ; Sat, 14 May 2016 20:01:28 -0700 (PDT) To: control@debbugs.gnu.org From: Paul Eggert Subject: 23529 needs more info Organization: UCLA Computer Science Department Message-ID: <5737E688.6060506@cs.ucla.edu> Date: Sat, 14 May 2016 20:01:28 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.4 (-) tags 23529 moreinfo From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Philippe Vaucher Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 17 May 2016 16:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Paul Eggert Cc: 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.14635031259177 (code B ref 23529); Tue, 17 May 2016 16:39:01 +0000 Received: (at 23529) by debbugs.gnu.org; 17 May 2016 16:38:45 +0000 Received: from localhost ([127.0.0.1]:56170 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b2i17-0002Nx-5b for submit@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 ) id 1b2i14-0002Nj-Ci for 23529@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@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: References: From: Philippe Vaucher Date: Tue, 17 May 2016 18:38:07 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Fri, May 13, 2016 at 5:58 PM, Paul Eggert 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 From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Philippe Vaucher Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 18 May 2016 07:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Paul Eggert Cc: 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.146355806928449 (code B ref 23529); Wed, 18 May 2016 07:55:01 +0000 Received: (at 23529) by debbugs.gnu.org; 18 May 2016 07:54:29 +0000 Received: from localhost ([127.0.0.1]:56497 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b2wJJ-0007On-K0 for submit@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 ) id 1b2wJH-0007Oa-VM for 23529@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@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: References: From: Philippe Vaucher Date: Wed, 18 May 2016 09:53:52 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 18 May 2016 08:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Philippe Vaucher Cc: 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.146355969930980 (code B ref 23529); Wed, 18 May 2016 08:22:01 +0000 Received: (at 23529) by debbugs.gnu.org; 18 May 2016 08:21:39 +0000 Received: from localhost ([127.0.0.1]:56520 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b2wjW-00083X-0W for submit@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 ) id 1b2wjU-00083I-7o for 23529@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 References: Organization: UCLA Computer Science Department Message-ID: <573C2601.3030308@cs.ucla.edu> 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: Content-Type: multipart/mixed; boundary="------------080307040907070706050206" X-Spam-Score: -1.4 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 . --------------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 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 , . =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 +. =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-- From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Philippe Vaucher Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 18 May 2016 08:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Paul Eggert Cc: 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.1463561115617 (code B ref 23529); Wed, 18 May 2016 08:46:02 +0000 Received: (at 23529) by debbugs.gnu.org; 18 May 2016 08:45:15 +0000 Received: from localhost ([127.0.0.1]:56525 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b2x6R-00009s-D5 for submit@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 ) id 1b2x6P-00009e-F7 for 23529@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@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@cs.ucla.edu> References: <573C2601.3030308@cs.ucla.edu> From: Philippe Vaucher Date: Wed, 18 May 2016 10:44:37 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 > . I'll play with it. Thanks! Philippe From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 20 May 2016 17:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Philippe Vaucher Cc: 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.146376678525238 (code B ref 23529); Fri, 20 May 2016 17:54:02 +0000 Received: (at 23529) by debbugs.gnu.org; 20 May 2016 17:53:05 +0000 Received: from localhost ([127.0.0.1]:59307 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b3obh-0006Z0-Gz for submit@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 ) id 1b3obf-0006YW-8Y for 23529@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) References: <573C2601.3030308@cs.ucla.edu> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 14 14:26:12 2016 Received: (at control) by debbugs.gnu.org; 14 Jun 2016 18:26:12 +0000 Received: from localhost ([127.0.0.1]:40843 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bCt2S-0007AS-09 for submit@debbugs.gnu.org; Tue, 14 Jun 2016 14:26:12 -0400 Received: from eggs.gnu.org ([208.118.235.92]:45569) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bCt2Q-0007AE-N3 for control@debbugs.gnu.org; Tue, 14 Jun 2016 14:26:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCt2K-0005Kx-Lp for control@debbugs.gnu.org; Tue, 14 Jun 2016 14:26:05 -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.3 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]:58144) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCt2K-0005Kq-IN for control@debbugs.gnu.org; Tue, 14 Jun 2016 14:26:04 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1bCt2J-0004NR-4b for control@debbugs.gnu.org; Tue, 14 Jun 2016 14:26:03 -0400 Subject: control message for bug 23529 To: X-Mailer: mail (GNU Mailutils 2.99.98) Message-Id: From: Glenn Morris Date: Tue, 14 Jun 2016 14:26:03 -0400 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.4 (------) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.4 (------) tag 23529 - moreinfo From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2016 09:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert , Philippe Vaucher Cc: 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147315379126436 (code B ref 23529); Tue, 06 Sep 2016 09:24:02 +0000 Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 09:23:11 +0000 Received: from localhost ([127.0.0.1]:50876 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhCb1-0006sI-7d for submit@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 ) id 1bhCay-0006s3-SL for 23529@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@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: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> In-Reply-To: <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> From: Philipp Stephani Date: Tue, 06 Sep 2016 09:22:52 +0000 Message-ID: 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 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


Paul E= ggert <eggert@cs.ucla.edu> = schrieb am Fr., 20. Mai 2016 um 19:54=C2=A0Uhr:
On 05/18/2016 01:44 AM, Philippe Vaucher wrote:
> About the dumping procedure, do you mean there*is*=C2=A0 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 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...).
--001a1146a152f1c91e053bd35735-- From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2016 17:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philipp Stephani , Philippe Vaucher Cc: 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147318327726529 (code B ref 23529); Tue, 06 Sep 2016 17:35:01 +0000 Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 17:34:37 +0000 Received: from localhost ([127.0.0.1]:51640 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhKGW-0006tk-3t for submit@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 ) id 1bhKGQ-0006tP-Ia for 23529@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) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2016 17:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147318368827169 (code B ref 23529); Tue, 06 Sep 2016 17:42:02 +0000 Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 17:41:28 +0000 Received: from localhost ([127.0.0.1]:51646 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhKNA-000745-D1 for submit@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 ) id 1bhKN5-00073n-5a for 23529@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 ) id 1bhKMw-0003EE-5Z for 23529@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii In-reply-to: <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> (message from Paul Eggert on Tue, 6 Sep 2016 10:21:15 -0700) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.1 (------) > From: Paul Eggert > Date: Tue, 6 Sep 2016 10:21:15 -0700 > Cc: 23529@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? From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Philippe Vaucher Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2016 17:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: p.stephani2@gmail.com, Paul Eggert , 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147318404627743 (code B ref 23529); Tue, 06 Sep 2016 17:48:02 +0000 Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 17:47:26 +0000 Received: from localhost ([127.0.0.1]:51654 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhKT0-0007DP-LR for submit@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 ) id 1bhKSy-0007D7-8a for 23529@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@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@gnu.org> References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> From: Philippe Vaucher Date: Tue, 6 Sep 2016 19:46:47 +0200 Message-ID: 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2016 17:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philippe Vaucher , Eli Zaretskii Cc: 23529@debbugs.gnu.org, Paul Eggert Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147318455928492 (code B ref 23529); Tue, 06 Sep 2016 17:56:02 +0000 Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 17:55:59 +0000 Received: from localhost ([127.0.0.1]:51659 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhKbH-0007PU-FB for submit@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 ) id 1bhKbG-0007PG-LI for 23529@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@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: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> In-Reply-To: From: Philipp Stephani Date: Tue, 06 Sep 2016 17:55:42 +0000 Message-ID: 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 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


Philip= pe Vaucher <philippe.vauch= er@gmail.com> schrieb am Di., 6. Sep. 2016 um 19:47=C2=A0Uhr:
>> My idea is pretty simple: just o= utput 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.=C2=A0
--047d7b10c7e7f75fdd053bda814e-- From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2016 18:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philippe Vaucher Cc: p.stephani2@gmail.com, eggert@cs.ucla.edu, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147318483229001 (code B ref 23529); Tue, 06 Sep 2016 18:01:02 +0000 Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 18:00:32 +0000 Received: from localhost ([127.0.0.1]:51663 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhKfg-0007Xg-0A for submit@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 ) id 1bhKfd-0007XQ-5n for 23529@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 ) id 1bhKfT-0007Ct-Hf for 23529@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii In-reply-to: (message from Philippe Vaucher on Tue, 6 Sep 2016 19:46:47 +0200) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.1 (------) > From: Philippe Vaucher > Date: Tue, 6 Sep 2016 19:46:47 +0200 > Cc: Paul Eggert , p.stephani2@gmail.com, 23529@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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2016 18:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Philippe Vaucher Cc: 23529@debbugs.gnu.org, eggert@cs.ucla.edu Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147318501129271 (code B ref 23529); Tue, 06 Sep 2016 18:04:02 +0000 Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 18:03:31 +0000 Received: from localhost ([127.0.0.1]:51667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhKiZ-0007c3-Gq for submit@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 ) id 1bhKiX-0007bp-UV for 23529@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@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: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <8337lcc3jf.fsf@gnu.org> In-Reply-To: <8337lcc3jf.fsf@gnu.org> From: Philipp Stephani Date: Tue, 06 Sep 2016 18:03:13 +0000 Message-ID: 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@gmail.com, > 23529@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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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@gmail.com, > 23529@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 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@gmail.com, > 23529@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


Eli Za= retskii <eliz@gnu.org> schrieb am= Di., 6. Sep. 2016 um 20:00=C2=A0Uhr:
> From: Philippe Vaucher <philippe.vaucher@gmail.com>
> Date: Tue, 6 Sep 2016 19:46:47 +0200
> Cc: Paul Eggert <eggert@cs.ucla.edu>, p.stephani2@gmail.com, 23529@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.=C2=A0 Whenever you
remove a feature, expect someone to come up with complaints about
regressions.

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
--047d7ba97a10df0999053bda9c92-- From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2016 18:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philipp Stephani Cc: philippe.vaucher@gmail.com, eggert@cs.ucla.edu, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147318511429443 (code B ref 23529); Tue, 06 Sep 2016 18:06:01 +0000 Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 18:05:14 +0000 Received: from localhost ([127.0.0.1]:51672 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhKkD-0007eo-Su for submit@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 ) id 1bhKkC-0007eT-BB for 23529@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 ) id 1bhKk3-0000S4-Js for 23529@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii In-reply-to: (message from Philipp Stephani on Tue, 06 Sep 2016 17:55:42 +0000) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.1 (------) > From: Philipp Stephani > Date: Tue, 06 Sep 2016 17:55:42 +0000 > Cc: Paul Eggert , 23529@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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2016 18:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 23529@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.147318593430682 (code B ref -1); Tue, 06 Sep 2016 18:19:01 +0000 Received: (at submit) by debbugs.gnu.org; 6 Sep 2016 18:18:54 +0000 Received: from localhost ([127.0.0.1]:51682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhKxS-0007yn-DI for submit@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 ) id 1bhKxQ-0007yY-80 for submit@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 ) id 1bhKxK-0002uz-AJ for submit@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 ) id 1bhKxK-0002ul-6t for submit@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 ) id 1bhKxI-0001nR-8B for bug-gnu-emacs@gnu.org; Tue, 06 Sep 2016 14:18:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhKxE-0002ts-UM for bug-gnu-emacs@gnu.org; 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 ) id 1bhKxE-0002tM-Jo for bug-gnu-emacs@gnu.org; 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 ; Tue, 06 Sep 2016 20:18:39 +0200 References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> From: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Message-ID: <07d39d22-0ab8-90c6-e20c-f70d29aa4809@gmail.com> 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@gnu.org> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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?= To: bug-gnu-emacs@gnu.org Message-ID: <07d39d22-0ab8-90c6-e20c-f70d29aa4809@gmail.com> Subject: Re: bug#23529: Request for fixing randomize_va_space build issues References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> In-Reply-To: <834m5tapuu.fsf@gnu.org> --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 >> Date: Tue, 6 Sep 2016 10:21:15 -0700 >> Cc: 23529@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-- From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Philippe Vaucher Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2016 18:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: p.stephani2@gmail.com, Paul Eggert , 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147318629931254 (code B ref 23529); Tue, 06 Sep 2016 18:25:02 +0000 Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 18:24:59 +0000 Received: from localhost ([127.0.0.1]:51686 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhL3L-000882-45 for submit@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 ) id 1bhL3K-00087q-7N for 23529@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@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@gnu.org> References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <8337lcc3jf.fsf@gnu.org> From: Philippe Vaucher Date: Tue, 6 Sep 2016 20:24:19 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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? From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2016 18:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philipp Stephani Cc: philippe.vaucher@gmail.com, eggert@cs.ucla.edu, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147318681032122 (code B ref 23529); Tue, 06 Sep 2016 18:34:02 +0000 Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 18:33:30 +0000 Received: from localhost ([127.0.0.1]:51691 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhLBZ-0008M2-Us for submit@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 ) id 1bhLBY-0008Lp-9d for 23529@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 ) id 1bhLBP-0005pf-TX for 23529@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii In-reply-to: (message from Philipp Stephani on Tue, 06 Sep 2016 18:03:13 +0000) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <8337lcc3jf.fsf@gnu.org> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.1 (------) > From: Philipp Stephani > Date: Tue, 06 Sep 2016 18:03:13 +0000 > Cc: eggert@cs.ucla.edu, 23529@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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2016 18:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.1473187545783 (code B ref 23529); Tue, 06 Sep 2016 18:46:01 +0000 Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 18:45:45 +0000 Received: from localhost ([127.0.0.1]:51697 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhLNR-0000CZ-4C for submit@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 ) id 1bhLNP-0000CL-Ok for 23529@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) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: 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@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2016 19:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: philippe.vaucher@gmail.com, eggert@cs.ucla.edu, 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.14731885412370 (code B ref 23529); Tue, 06 Sep 2016 19:03:01 +0000 Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 19:02:21 +0000 Received: from localhost ([127.0.0.1]:51706 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhLdU-0000c9-0z for submit@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 ) id 1bhLdM-0000bn-Eq for 23529@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@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: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <8337lcc3jf.fsf@gnu.org> <83zinkanfw.fsf@gnu.org> In-Reply-To: <83zinkanfw.fsf@gnu.org> From: Philipp Stephani Date: Tue, 06 Sep 2016 19:01:53 +0000 Message-ID: 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 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


Eli Za= retskii <eliz@gnu.org> schrieb am= Di., 6. Sep. 2016 um 20:33=C2=A0Uhr:
> That will be a bit slower, but that might be OK.

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

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.
=C2= =A0
--001a114b3e52b80b5f053bdb6efe-- From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2016 19:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Cc: 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.14731889973111 (code B ref 23529); Tue, 06 Sep 2016 19:10:02 +0000 Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 19:09:57 +0000 Received: from localhost ([127.0.0.1]:51724 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhLkr-0000o7-4j for submit@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 ) id 1bhLkq-0000nv-5j for 23529@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 ) id 1bhLkh-0005GI-Uc for 23529@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii In-reply-to: <07d39d22-0ab8-90c6-e20c-f70d29aa4809@gmail.com> (message from =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel on Tue, 6 Sep 2016 14:18:38 -0400) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <07d39d22-0ab8-90c6-e20c-f70d29aa4809@gmail.com> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.1 (------) > 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2016 19:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philippe Vaucher Cc: p.stephani2@gmail.com, eggert@cs.ucla.edu, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.14731891243321 (code B ref 23529); Tue, 06 Sep 2016 19:13:01 +0000 Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 19:12:04 +0000 Received: from localhost ([127.0.0.1]:51729 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhLmu-0000rV-HM for submit@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 ) id 1bhLmt-0000r3-C6 for 23529@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 ) id 1bhLml-00060U-4F for 23529@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii In-reply-to: (message from Philippe Vaucher on Tue, 6 Sep 2016 20:24:19 +0200) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <8337lcc3jf.fsf@gnu.org> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.1 (------) > From: Philippe Vaucher > Date: Tue, 6 Sep 2016 20:24:19 +0200 > Cc: Paul Eggert , p.stephani2@gmail.com, 23529@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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2016 19:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.14731895604057 (code B ref 23529); Tue, 06 Sep 2016 19:20:01 +0000 Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 19:19:20 +0000 Received: from localhost ([127.0.0.1]:51733 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhLtw-00013N-9B for submit@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 ) id 1bhLtv-00013B-6b for 23529@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 ) id 1bhLtm-0007jc-UX for 23529@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii In-reply-to: (message from Paul Eggert on Tue, 6 Sep 2016 11:44:57 -0700) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.1 (------) > Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org > From: Paul Eggert > 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2016 20:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.14731920747644 (code B ref 23529); Tue, 06 Sep 2016 20:02:02 +0000 Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 20:01:14 +0000 Received: from localhost ([127.0.0.1]:51747 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhMYE-0001yV-So for submit@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 ) id 1bhMXy-0001vT-30 for 23529@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 References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <07d39d22-0ab8-90c6-e20c-f70d29aa4809@gmail.com> <83wpioalr3.fsf@gnu.org> From: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Message-ID: <0dc33671-4b05-7512-4790-a066b59faf55@gmail.com> 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@gnu.org> 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: =?UTF-8?Q?Cl=E9ment?= 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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: =?UTF-8?Q?Cl=E9ment?= 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?= To: Eli Zaretskii Cc: 23529@debbugs.gnu.org Message-ID: <0dc33671-4b05-7512-4790-a066b59faf55@gmail.com> Subject: Re: bug#23529: Request for fixing randomize_va_space build issues References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <07d39d22-0ab8-90c6-e20c-f70d29aa4809@gmail.com> <83wpioalr3.fsf@gnu.org> In-Reply-To: <83wpioalr3.fsf@gnu.org> --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 >> 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-- From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2016 20:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147319433710975 (code B ref 23529); Tue, 06 Sep 2016 20:39:02 +0000 Received: (at 23529) by debbugs.gnu.org; 6 Sep 2016 20:38:57 +0000 Received: from localhost ([127.0.0.1]:51750 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhN8j-0002qi-Q4 for submit@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 ) id 1bhN8S-0002ot-VX for 23529@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) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: 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@gnu.org> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Philippe Vaucher Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Sep 2016 07:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert Cc: Eli Zaretskii , p.stephani2@gmail.com, 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147323238211427 (code B ref 23529); Wed, 07 Sep 2016 07:14:01 +0000 Received: (at 23529) by debbugs.gnu.org; 7 Sep 2016 07:13:02 +0000 Received: from localhost ([127.0.0.1]:51868 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhX2b-0002y7-RG for submit@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 ) id 1bhX2a-0002xm-Fi for 23529@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@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: References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> From: Philippe Vaucher Date: Wed, 7 Sep 2016 09:12:24 +0200 Message-ID: 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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
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.

I agree.

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

Philippe=C2=A0
<= /div>
--001a11427d1a635203053be5a446-- From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Sep 2016 07:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philippe Vaucher Cc: Eli Zaretskii , p.stephani2@gmail.com, 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147323403413928 (code B ref 23529); Wed, 07 Sep 2016 07:41:01 +0000 Received: (at 23529) by debbugs.gnu.org; 7 Sep 2016 07:40:34 +0000 Received: from localhost ([127.0.0.1]:51885 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhXTG-0003cZ-BZ for submit@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 ) id 1bhXTF-0003cM-Be for 23529@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) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <1a792452-b263-48a8-0adc-0b984315649e@cs.ucla.edu> 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Sep 2016 11:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert , Philippe Vaucher Cc: Eli Zaretskii , 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.1473246131374 (code B ref 23529); Wed, 07 Sep 2016 11:03:01 +0000 Received: (at 23529) by debbugs.gnu.org; 7 Sep 2016 11:02:11 +0000 Received: from localhost ([127.0.0.1]:51941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhacM-00005y-QO for submit@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 ) id 1bhacK-00005m-QM for 23529@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@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: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <1a792452-b263-48a8-0adc-0b984315649e@cs.ucla.edu> In-Reply-To: <1a792452-b263-48a8-0adc-0b984315649e@cs.ucla.edu> From: Philipp Stephani Date: Wed, 07 Sep 2016 11:01:52 +0000 Message-ID: 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 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


Paul E= ggert <eggert@cs.ucla.edu> = schrieb am Mi., 7. Sep. 2016 um 09:40=C2=A0Uhr:
Philippe Vaucher wrote:
> Would that also avoid having to require special privileges when buildi= ng?
> e.g the "personality" syscall.

I hope not.

I hope = you mean "I hope so" :)
I think any new dumper should b= e portable enough to work with ASLR, ASan, ... (essentially just portable C= code).=C2=A0
--001a1146a152d3a78f053be8d7df-- From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Sep 2016 14:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147325814625720 (code B ref 23529); Wed, 07 Sep 2016 14:23:02 +0000 Received: (at 23529) by debbugs.gnu.org; 7 Sep 2016 14:22:26 +0000 Received: from localhost ([127.0.0.1]:52762 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhdk9-0006gl-T6 for submit@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 ) id 1bhdk5-0006gR-Tl for 23529@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 ) id 1bhdjx-0000KY-6y for 23529@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii In-reply-to: (message from Paul Eggert on Tue, 6 Sep 2016 13:37:20 -0700) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.1 (------) > Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org > From: Paul Eggert > 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? From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Sep 2016 16:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147326470415662 (code B ref 23529); Wed, 07 Sep 2016 16:12:01 +0000 Received: (at 23529) by debbugs.gnu.org; 7 Sep 2016 16:11:44 +0000 Received: from localhost ([127.0.0.1]:52833 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhfRw-00044Y-55 for submit@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 ) id 1bhfRu-00044M-HT for 23529@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) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: 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@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Sep 2016 17:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147326826921249 (code B ref 23529); Wed, 07 Sep 2016 17:12:02 +0000 Received: (at 23529) by debbugs.gnu.org; 7 Sep 2016 17:11:09 +0000 Received: from localhost ([127.0.0.1]:52852 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhgNR-0005Wf-IQ for submit@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 ) id 1bhgNP-0005WH-DX for 23529@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 ) id 1bhgNH-0001Qi-3W for 23529@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii In-reply-to: (message from Paul Eggert on Wed, 7 Sep 2016 09:11:31 -0700) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.1 (------) > Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org > From: Paul Eggert > 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Sep 2016 17:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147327002323879 (code B ref 23529); Wed, 07 Sep 2016 17:41:02 +0000 Received: (at 23529) by debbugs.gnu.org; 7 Sep 2016 17:40:23 +0000 Received: from localhost ([127.0.0.1]:52861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhgpj-0006D5-9F for submit@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 ) id 1bhgph-0006Cp-8X for 23529@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) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: 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@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.1 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Sep 2016 18:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147327192026810 (code B ref 23529); Wed, 07 Sep 2016 18:12:01 +0000 Received: (at 23529) by debbugs.gnu.org; 7 Sep 2016 18:12:00 +0000 Received: from localhost ([127.0.0.1]:52872 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhhKK-0006yL-92 for submit@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 ) id 1bhhKI-0006y6-I6 for 23529@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 ) id 1bhhKA-0004vy-7K for 23529@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii In-reply-to: (message from Paul Eggert on Wed, 7 Sep 2016 10:40:14 -0700) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.1 (------) > Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org > From: Paul Eggert > 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Sep 2016 20:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.14732791605472 (code B ref 23529); Wed, 07 Sep 2016 20:13:01 +0000 Received: (at 23529) by debbugs.gnu.org; 7 Sep 2016 20:12:40 +0000 Received: from localhost ([127.0.0.1]:52918 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhjD6-0001QC-I5 for submit@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 ) id 1bhjD4-0001Py-8R for 23529@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) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> 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@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Sep 2016 05:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147339967121693 (code B ref 23529); Fri, 09 Sep 2016 05:42:02 +0000 Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 05:41:11 +0000 Received: from localhost ([127.0.0.1]:54102 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biEYo-0005dp-NF for submit@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 ) id 1biEYn-0005db-M0 for 23529@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 ) id 1biEYf-00014I-9O for 23529@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii In-reply-to: <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> (message from Paul Eggert on Wed, 7 Sep 2016 13:12:27 -0700) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.3 (------) > Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org > From: Paul Eggert > 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Sep 2016 07:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147340503329800 (code B ref 23529); Fri, 09 Sep 2016 07:11:02 +0000 Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 07:10:33 +0000 Received: from localhost ([127.0.0.1]:54135 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biFxJ-0007kZ-2o for submit@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 ) id 1biFxG-0007kL-MM for 23529@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) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> 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@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Sep 2016 07:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.14734074581036 (code B ref 23529); Fri, 09 Sep 2016 07:51:02 +0000 Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 07:50:58 +0000 Received: from localhost ([127.0.0.1]:54158 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biGaQ-0000Gd-A4 for submit@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 ) id 1biGaO-0000GN-AV for 23529@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 ) id 1biGaE-0003T2-J1 for 23529@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii In-reply-to: <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> (message from Paul Eggert on Fri, 9 Sep 2016 00:10:22 -0700) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.3 (------) > Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org > From: Paul Eggert > 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Sep 2016 08:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.14734112576771 (code B ref 23529); Fri, 09 Sep 2016 08:55:02 +0000 Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 08:54:17 +0000 Received: from localhost ([127.0.0.1]:54188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biHZg-0001l8-Ov for submit@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 ) id 1biHZf-0001kw-4X for 23529@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) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: 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@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Sep 2016 09:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.14734121998205 (code B ref 23529); Fri, 09 Sep 2016 09:10:02 +0000 Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 09:09:59 +0000 Received: from localhost ([127.0.0.1]:54197 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biHot-00028H-4D for submit@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 ) id 1biHor-000285-8o for 23529@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 ) id 1biHoh-0007QS-CU for 23529@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii In-reply-to: (message from Paul Eggert on Fri, 9 Sep 2016 01:54:07 -0700) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.3 (------) > Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org > From: Paul Eggert > 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Sep 2016 16:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147343781029877 (code B ref 23529); Fri, 09 Sep 2016 16:17:01 +0000 Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 16:16:50 +0000 Received: from localhost ([127.0.0.1]:54814 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biOTy-0007lp-8s for submit@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 ) id 1biOTw-0007lc-45 for 23529@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) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: 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@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Andreas Schwab Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Sep 2016 18:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: p.stephani2@gmail.com, Paul Eggert , philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147344577622399 (code B ref 23529); Fri, 09 Sep 2016 18:30:02 +0000 Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 18:29:36 +0000 Received: from localhost ([127.0.0.1]:54870 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biQYR-0005pC-Q8 for submit@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 ) id 1biQYP-0005p4-Hn for 23529@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 References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> 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@gnu.org> (Eli Zaretskii's message of "Fri, 09 Sep 2016 08:40:50 +0300") Message-ID: <87sht9ncz9.fsf@linux-m68k.org> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Sep 09 2016, Eli Zaretskii 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@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Sep 2016 18:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147344679324044 (code B ref 23529); Fri, 09 Sep 2016 18:47:02 +0000 Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 18:46:33 +0000 Received: from localhost ([127.0.0.1]:54876 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biQor-0006Fj-Ac for submit@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 ) id 1biQop-0006FX-CZ for 23529@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 ) id 1biQof-0005g5-LX for 23529@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii In-reply-to: (message from Paul Eggert on Fri, 9 Sep 2016 09:16:39 -0700) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.3 (------) > Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org > From: Paul Eggert > 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Sep 2016 18:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Andreas Schwab Cc: p.stephani2@gmail.com, eggert@cs.ucla.edu, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147344739024942 (code B ref 23529); Fri, 09 Sep 2016 18:57:01 +0000 Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 18:56:30 +0000 Received: from localhost ([127.0.0.1]:54880 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biQyU-0006UD-C5 for submit@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 ) id 1biQyT-0006U2-78 for 23529@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 ) id 1biQyK-0008IZ-U4 for 23529@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii In-reply-to: <87sht9ncz9.fsf@linux-m68k.org> (message from Andreas Schwab on Fri, 09 Sep 2016 20:29:30 +0200) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <87sht9ncz9.fsf@linux-m68k.org> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.3 (------) > From: Andreas Schwab > Cc: Paul Eggert , p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org > Date: Fri, 09 Sep 2016 20:29:30 +0200 > > On Sep 09 2016, Eli Zaretskii 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? From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Sep 2016 20:00:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147345116531522 (code B ref 23529); Fri, 09 Sep 2016 20:00:03 +0000 Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 19:59:25 +0000 Received: from localhost ([127.0.0.1]:54905 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biRxM-0008CM-Ps for submit@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 ) id 1biRxL-0008C4-EC for 23529@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) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> 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@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Philippe Vaucher Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Sep 2016 20:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert Cc: Philipp Stephani , Eli Zaretskii , 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147345125231738 (code B ref 23529); Fri, 09 Sep 2016 20:01:01 +0000 Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 20:00:52 +0000 Received: from localhost ([127.0.0.1]:54909 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biRym-0008Fq-4J for submit@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 ) id 1biRyk-0008Fb-NF for 23529@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@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: References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> From: Philippe Vaucher Date: Fri, 9 Sep 2016 22:00:43 +0200 Message-ID: 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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

>> A typical non-trivial Emacs session takes several s= econds, sometimes
>> 25 or more, to start
>
> ?!=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'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.

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.

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

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

Philippe

--001a114316d40db805053c189ae8-- From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Sep 2016 06:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147348760329816 (code B ref 23529); Sat, 10 Sep 2016 06:07:01 +0000 Received: (at 23529) by debbugs.gnu.org; 10 Sep 2016 06:06:43 +0000 Received: from localhost ([127.0.0.1]:55065 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bibR4-0007kq-M3 for submit@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 ) id 1bibR3-0007kd-33 for 23529@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 ) id 1bibQt-0006HS-FL for 23529@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii In-reply-to: <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> (message from Paul Eggert on Fri, 9 Sep 2016 12:59:16 -0700) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.3 (------) > Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org > From: Paul Eggert > 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 > 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Sep 2016 06:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philippe Vaucher Cc: p.stephani2@gmail.com, eggert@cs.ucla.edu, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147348801230407 (code B ref 23529); Sat, 10 Sep 2016 06:14:02 +0000 Received: (at 23529) by debbugs.gnu.org; 10 Sep 2016 06:13:32 +0000 Received: from localhost ([127.0.0.1]:55069 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bibXg-0007uN-IH for submit@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 ) id 1bibXf-0007uB-Da for 23529@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 ) id 1bibXW-0007V5-40 for 23529@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii In-reply-to: (message from Philippe Vaucher on Fri, 9 Sep 2016 22:00:43 +0200) References: <573C2601.3030308@cs.ucla.edu> <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.3 (------) > From: Philippe Vaucher > Date: Fri, 9 Sep 2016 22:00:43 +0200 > Cc: Philipp Stephani , 23529@debbugs.gnu.org, > Eli Zaretskii > > >> 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Sep 2016 07:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.14734939676861 (code B ref 23529); Sat, 10 Sep 2016 07:53:02 +0000 Received: (at 23529) by debbugs.gnu.org; 10 Sep 2016 07:52:47 +0000 Received: from localhost ([127.0.0.1]:55114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bid5j-0001mb-Ft for submit@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 ) id 1bid5h-0001mN-NQ for 23529@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) References: <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> <83wpik8f18.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> 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@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Sep 2016 10:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147350280226269 (code B ref 23529); Sat, 10 Sep 2016 10:21:02 +0000 Received: (at 23529) by debbugs.gnu.org; 10 Sep 2016 10:20:02 +0000 Received: from localhost ([127.0.0.1]:55156 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bifOD-0006pR-3U for submit@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 ) id 1bifOB-0006pF-M8 for 23529@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 ) id 1bifO2-0007jC-0J for 23529@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii In-reply-to: <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> (message from Paul Eggert on Sat, 10 Sep 2016 00:52:33 -0700) References: <54b89449-083a-a906-986a-f284dbbf482a@cs.ucla.edu> <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> <83wpik8f18.fsf@gnu.org> <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.3 (------) > Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org > From: Paul Eggert > 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Sep 2016 23:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147354849824347 (code B ref 23529); Sat, 10 Sep 2016 23:02:01 +0000 Received: (at 23529) by debbugs.gnu.org; 10 Sep 2016 23:01:38 +0000 Received: from localhost ([127.0.0.1]:55828 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1birHF-0006Kd-Py for submit@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 ) id 1birHE-0006KR-DB for 23529@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) References: <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> <83wpik8f18.fsf@gnu.org> <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> <83k2ek83b7.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <24612cc1-cb72-511f-7d52-bb62101906ae@cs.ucla.edu> 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@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Sep 2016 15:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.14736074193757 (code B ref 23529); Sun, 11 Sep 2016 15:24:02 +0000 Received: (at 23529) by debbugs.gnu.org; 11 Sep 2016 15:23:39 +0000 Received: from localhost ([127.0.0.1]:56556 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bj6bb-0000yX-9f for submit@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 ) id 1bj6bZ-0000yK-7C for 23529@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 ) id 1bj6bQ-0002Oc-W5 for 23529@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii In-reply-to: <24612cc1-cb72-511f-7d52-bb62101906ae@cs.ucla.edu> (message from Paul Eggert on Sat, 10 Sep 2016 16:01:28 -0700) References: <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> <83wpik8f18.fsf@gnu.org> <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> <83k2ek83b7.fsf@gnu.org> <24612cc1-cb72-511f-7d52-bb62101906ae@cs.ucla.edu> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.2 (-------) > Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org > From: Paul Eggert > 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Sep 2016 17:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147361320213199 (code B ref 23529); Sun, 11 Sep 2016 17:01:01 +0000 Received: (at 23529) by debbugs.gnu.org; 11 Sep 2016 17:00:02 +0000 Received: from localhost ([127.0.0.1]:56662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bj86r-0003Qk-K7 for submit@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 ) id 1bj86p-0003Q6-Pg for 23529@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) References: <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> <83wpik8f18.fsf@gnu.org> <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> <83k2ek83b7.fsf@gnu.org> <24612cc1-cb72-511f-7d52-bb62101906ae@cs.ucla.edu> <83fup6bguo.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <2112c911-8613-01fd-2ec5-dfc29002acce@cs.ucla.edu> 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@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Sep 2016 17:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147361439615101 (code B ref 23529); Sun, 11 Sep 2016 17:20:02 +0000 Received: (at 23529) by debbugs.gnu.org; 11 Sep 2016 17:19:56 +0000 Received: from localhost ([127.0.0.1]:56678 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bj8Q7-0003vV-To for submit@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 ) id 1bj8Q5-0003vI-HI for 23529@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 ) id 1bj8Px-0001eD-DQ for 23529@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii In-reply-to: <2112c911-8613-01fd-2ec5-dfc29002acce@cs.ucla.edu> (message from Paul Eggert on Sun, 11 Sep 2016 09:59:52 -0700) References: <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> <83wpik8f18.fsf@gnu.org> <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> <83k2ek83b7.fsf@gnu.org> <24612cc1-cb72-511f-7d52-bb62101906ae@cs.ucla.edu> <83fup6bguo.fsf@gnu.org> <2112c911-8613-01fd-2ec5-dfc29002acce@cs.ucla.edu> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.2 (-------) > Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org > From: Paul Eggert > 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. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Philippe Vaucher Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Sep 2016 19:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Philipp Stephani , Paul Eggert , 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.1473622409960 (code B ref 23529); Sun, 11 Sep 2016 19:34:01 +0000 Received: (at 23529) by debbugs.gnu.org; 11 Sep 2016 19:33:29 +0000 Received: from localhost ([127.0.0.1]:56790 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjAVN-0000FQ-64 for submit@debbugs.gnu.org; Sun, 11 Sep 2016 15:33:29 -0400 Received: from mail-vk0-f48.google.com ([209.85.213.48]:35887) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjAVL-0000FC-EA for 23529@debbugs.gnu.org; Sun, 11 Sep 2016 15:33:27 -0400 Received: by mail-vk0-f48.google.com with SMTP id m62so54441911vkd.3 for <23529@debbugs.gnu.org>; Sun, 11 Sep 2016 12:33: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=avcVNRx3/coMs1TNqkoRkqRqkvc+WoqbwqW0AGVj8mg=; b=SAAESQ7W9Pe+MDA6ZIsHspUa6bmUv0+zyyUs4h5LUqx/X2U2bUmlTh5T4PD9Gpw9fd 5sVtsO6UbgeCdTEeEo94rD6HY+21+JP9dIyAJABQz27R+WavbgvLEl78Y4HKBPxaYa+I M8FN8zQ4LEr+8NjZBN2KRSeFH9ynlphW+g5QJHmsTD7ERKwMWfHn9gUSJgn9SP6HsvZw 6DJbuApUPpXIrxi3Zci2YdL4osWihwGq6vuUU2vAPz0AQECMsT2J+ATxF6AMcaDQTjB7 m8J5NUGHDXckFC2duaZ/Ml+rB1RGhfNDsFsEazINjH1+8yrDrlfA0u56tVlXhJmfAzUN cP7g== 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=avcVNRx3/coMs1TNqkoRkqRqkvc+WoqbwqW0AGVj8mg=; b=G12+wVWks2INtzEHe0DSRV7m5JyXD133Zs7E5I5KETZjTyZFhr8PssTTf5zcQ17izh CLcedXHEz06/c2OeWP9psCP36cGbaqDAm70uSHCbp1h9XGBL7xOnq/9WKn/kx8Cag8vc hgRSl99z5AHIbN7Ya/MIUkfak+Wl2I+8U75Gz196P9fDijvRL+wxgFw+QDq9cT+i+Hc5 RANq0NIYpoGhtnDUfCTsmqkmhUVrKG4fFl/7Sr+Fy6cRRiUZ/7ETAchKobU5ANJutAoP PQ2MF96DbO3fY0rKOUcRVBKhAkiQ0iYQJoGyKS9kEytsRY/8xRW/uOD84GH7JKy49Bsf aiOw== X-Gm-Message-State: AE9vXwNl73EaQiSqQ5jns1HK7k8XMfq77lt8vJ5clwMzP4O25Q8Il6iR7PNfBxgVRb99P652X+onk8Rt5xiKtg== X-Received: by 10.31.156.77 with SMTP id f74mr8136803vke.154.1473622401792; Sun, 11 Sep 2016 12:33:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.44.18 with HTTP; Sun, 11 Sep 2016 12:32:51 -0700 (PDT) In-Reply-To: <83fup6bguo.fsf@gnu.org> References: <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> <83wpik8f18.fsf@gnu.org> <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> <83k2ek83b7.fsf@gnu.org> <24612cc1-cb72-511f-7d52-bb62101906ae@cs.ucla.edu> <83fup6bguo.fsf@gnu.org> From: Philippe Vaucher Date: Sun, 11 Sep 2016 21:32:51 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> 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? That is exactly why I made the bug report 23529! Because Emacs does stuffs at build time that requires "high" privileges (like the personality() syscall), one cannot build Emacs in various restricted environments. Disabling randomization is exactly what we should get rid of, at least at build time. Having some part of emacs that requires somewhat high privileges when it runs is ok, but that should *not* be part of the standard build procedure... Being able to build GCC inside a container but not Emacs is just "wrong" IMHO. Philippe From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Sep 2016 02:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philippe Vaucher Cc: p.stephani2@gmail.com, eggert@cs.ucla.edu, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.14736474675735 (code B ref 23529); Mon, 12 Sep 2016 02:32:01 +0000 Received: (at 23529) by debbugs.gnu.org; 12 Sep 2016 02:31:07 +0000 Received: from localhost ([127.0.0.1]:56875 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjH1X-0001UR-Fq for submit@debbugs.gnu.org; Sun, 11 Sep 2016 22:31:07 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37136) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjH1V-0001Tl-M8 for 23529@debbugs.gnu.org; Sun, 11 Sep 2016 22:31:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bjH1H-0006aL-7l for 23529@debbugs.gnu.org; Sun, 11 Sep 2016 22:30: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=-2.2 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]:56643) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjH1H-0006a1-3v; Sun, 11 Sep 2016 22:30:51 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1551 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bjH1G-0002Es-17; Sun, 11 Sep 2016 22:30:50 -0400 Date: Mon, 12 Sep 2016 05:30:51 +0300 Message-Id: <83poo9alyc.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Philippe Vaucher on Sun, 11 Sep 2016 21:32:51 +0200) References: <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> <83wpik8f18.fsf@gnu.org> <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> <83k2ek83b7.fsf@gnu.org> <24612cc1-cb72-511f-7d52-bb62101906ae@cs.ucla.edu> <83fup6bguo.fsf@gnu.org> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.2 (-------) > From: Philippe Vaucher > Date: Sun, 11 Sep 2016 21:32:51 +0200 > Cc: Paul Eggert , Philipp Stephani , 23529@debbugs.gnu.org > > >> 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? > > That is exactly why I made the bug report 23529! > > Because Emacs does stuffs at build time that requires "high" > privileges (like the personality() syscall), one cannot build Emacs in > various restricted environments. > > Disabling randomization is exactly what we should get rid of, at least > at build time. Isn't it the other way around: the first priority is to enable randomization and all the other modern techniques for running the dumped Emacs? From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Sep 2016 02:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 23529@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.14736491218177 (code B ref -1); Mon, 12 Sep 2016 02:59:02 +0000 Received: (at submit) by debbugs.gnu.org; 12 Sep 2016 02:58:41 +0000 Received: from localhost ([127.0.0.1]:56898 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjHSD-00027p-6Y for submit@debbugs.gnu.org; Sun, 11 Sep 2016 22:58:41 -0400 Received: from eggs.gnu.org ([208.118.235.92]:40515) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjHSC-00027d-C7 for submit@debbugs.gnu.org; Sun, 11 Sep 2016 22:58:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bjHS6-0007xK-FI for submit@debbugs.gnu.org; Sun, 11 Sep 2016 22:58:35 -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, RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:36387) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjHS6-0007x1-BW for submit@debbugs.gnu.org; Sun, 11 Sep 2016 22:58:34 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjHS4-00072j-0q for bug-gnu-emacs@gnu.org; Sun, 11 Sep 2016 22:58:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bjHRz-0007vV-3Z for bug-gnu-emacs@gnu.org; Sun, 11 Sep 2016 22:58:32 -0400 Received: from mout.kundenserver.de ([212.227.126.130]:58430) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjHRy-0007nr-Om for bug-gnu-emacs@gnu.org; Sun, 11 Sep 2016 22:58:27 -0400 Received: from [18.189.118.169] ([18.189.118.169]) by mrelayeu.kundenserver.de (mreue002) with ESMTPSA (Nemesis) id 0M5lI9-1aqjoL0Mpd-00xqSL for ; Mon, 12 Sep 2016 04:58:04 +0200 References: <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> <83wpik8f18.fsf@gnu.org> <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> <83k2ek83b7.fsf@gnu.org> <24612cc1-cb72-511f-7d52-bb62101906ae@cs.ucla.edu> <83fup6bguo.fsf@gnu.org> <83poo9alyc.fsf@gnu.org> From: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Message-ID: <8db7f4c1-8b81-605f-8480-c740d524ccae@gmail.com> Date: Sun, 11 Sep 2016 22:58:03 -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: <83poo9alyc.fsf@gnu.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5IWAc4qcfTiP1b213F4UuQUqGJ4SeutIP" X-Provags-ID: V03:K0:eWKiFYqRhcuGcAryviMwDEv2T9PP9IduxgWatwOOOG3ncpdCeGC 35g5Tr5Gu3le12vP2/U3qzQT4gQs6+KUTNSH6xWH7RXe6LCt4GLESrOHDlSugpmws0rAyB+ HQvTDMouS0q5h4DKJ0mT87nhE/ksRLUUH2AFZE9sknMQ5pBfe1rHJOc3Hn/40RwdMbpXbx5 bMth0SdOkE7NfOX/wI1kw== X-UI-Out-Filterresults: notjunk:1;V01:K0:LvJocoj1/jI=:fPE6n7dXMYk3JVuyNq36bn vG0kdpd64gOroSEW/1hMiV6ATmHC3FhVsI89tqcVoXCDK8Lxn/IjXMd6CgPWn16ky+pUZr+BJ ibNEfVD+txcrVqmb90lGff5RFbT8jZs2e7Y1FnuccRj6QBAZ/7IBO6Uri9Bs4FA5imO6hIKF7 2WvboLmm2RKnWbZDJRHzqE81ZPjh2CL/NiFdw04YxXX7NFt+d/oZmRn5fxXZa6nc2HcTMq0vv hZIckPE8TcFOCAhqrQqp8LmdKMSsq99h2/t8/Ib8xRnDnSGhWhVW+RcvnyrAgSOfiIgO37d6p 7JEm/MpAXSXLmoVzSrrp4KJSPWYpaEvnypDHVPg0iI9teeV5VZPkKRwj3/wPaW4xR3S+OpkjV E8SloYTVVVxkjdryhSJT+ky/hDZdZVLSb1mRGQxvrdc1kKE9XEZz+5tS6QwKIZlW7rDwqun+N LfIhMJEPD5mlH/+iPJkCxE4jcV7BP7GEYfUQG9RpojT8ZsKOtxuOLfI5vn9e8N4N3j8zu0oVO a4TrPTvtxVx1zEeJ4mGzt4e6lekbslbOZZfgrB5bJn1Visv8QWieBvsevNi23AQLEpdeZ6Qj3 j30UsaNRO/hdmZULz8DN+YSdcChRSEbLllOFr2tu1RK1fRpTAMeZGpuTm0cKSOGxqvZlgCF9Z RLjZtwWxy2u/qTSstiB6rvrmuV8awpUteAsCGJQXEArABCicyHT4DJiof4wn3sjK1htg= 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5IWAc4qcfTiP1b213F4UuQUqGJ4SeutIP Content-Type: multipart/mixed; boundary="CW0mcBmdojLppAXKcveCwHXaQFWKIwKGe"; protected-headers="v1" From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= To: bug-gnu-emacs@gnu.org Message-ID: <8db7f4c1-8b81-605f-8480-c740d524ccae@gmail.com> Subject: Re: bug#23529: Request for fixing randomize_va_space build issues References: <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> <83wpik8f18.fsf@gnu.org> <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> <83k2ek83b7.fsf@gnu.org> <24612cc1-cb72-511f-7d52-bb62101906ae@cs.ucla.edu> <83fup6bguo.fsf@gnu.org> <83poo9alyc.fsf@gnu.org> In-Reply-To: <83poo9alyc.fsf@gnu.org> --CW0mcBmdojLppAXKcveCwHXaQFWKIwKGe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2016-09-11 22:30, Eli Zaretskii wrote: >> From: Philippe Vaucher >> Date: Sun, 11 Sep 2016 21:32:51 +0200 >> Cc: Paul Eggert , Philipp Stephani , 23529@debbugs.gnu.org >> >>>> What about disabling randomization for the temacs run? >>>> >>>> That is yet another low-level thing to configure, and to get right i= n new ports. >>> >>> We already have that in Emacs, don't we? >> >> That is exactly why I made the bug report 23529! >> >> Because Emacs does stuffs at build time that requires "high" >> privileges (like the personality() syscall), one cannot build Emacs in= >> various restricted environments. >> >> Disabling randomization is exactly what we should get rid of, at least= >> at build time. >=20 > Isn't it the other way around: the first priority is to enable > randomization and all the other modern techniques for running the > dumped Emacs? I think we want to be able to build the full Emacs in a container; that i= s without needing, at any point in the process, to disable randomization.= If I understand correctly, this means that even the process of dumping = Emacs cannot involve disabling randomization. Cl=E9ment. --CW0mcBmdojLppAXKcveCwHXaQFWKIwKGe-- --5IWAc4qcfTiP1b213F4UuQUqGJ4SeutIP 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 iQIcBAEBCAAGBQJX1hm7AAoJEPqg+cTm90wjtr0P/0fne0bRiHJ5NQEqVA7FQCNU WIZpj8ysncqadETti+ZnsMjZddoljtzs2s8tdvfKRLgE5gNYZR2S0KcJtBbSIVUE UanWl7Av6lOkUnN0Am5PkTD+aQsL7YHGpxUfdUSbzrsIyecX3H+++wabNZAnh25A JK/vgfDkPDvaHoo5TwJOzcvTEKjK/62jGLFVCSqZuUFIlCzTvB+7DnRRtDy5THUV FGN6uB2e18eQZWgPi1Al7pCDInL+0ia7116cssH6sE239rLVbz18n0kUEHsMIY50 o976OSCWCCIjb3XvBxkpBsOGpqwtcVmLIjEbO8Owp8bivYnRE0qJNteWgyGp6BlW C4OHo6EhIrAl6XUQNyNyAZIV7akSNGGZeLgbnkAu/1TaGQz8uRsZ+rx2sFG1n1Kz +ufjNOG9/tNQtym3xbgkaVd0ZFzVcLzkQREEYqrqSdKjEAJkgF7zqML5dnTVeuSg Fj5tCblZ9hmlesJ06EZOciBrVJcnxM61cGFediWa/Tey4VE8znqir5wkcuSomxQB xV+LNFUQSciAAlmFGxEbG/+7Z+8Cv6JljXb5FwO4IJv6hX+2XPKSnCXrgrzADNu0 10+2uKH4Ni2zBMQpDZAyMScSk1pUvwqE99c0qhJrNZlw8gvGsKa+XKrflZOBeXvE JMtbxiiMkBDC5O8640yA =Rm26 -----END PGP SIGNATURE----- --5IWAc4qcfTiP1b213F4UuQUqGJ4SeutIP-- From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Sep 2016 06:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel , 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147366056826243 (code B ref 23529); Mon, 12 Sep 2016 06:10:02 +0000 Received: (at 23529) by debbugs.gnu.org; 12 Sep 2016 06:09:28 +0000 Received: from localhost ([127.0.0.1]:56960 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjKQq-0006pD-GY for submit@debbugs.gnu.org; Mon, 12 Sep 2016 02:09:28 -0400 Received: from mail-wm0-f44.google.com ([74.125.82.44]:36941) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjKQo-0006oz-Ep for 23529@debbugs.gnu.org; Mon, 12 Sep 2016 02:09:27 -0400 Received: by mail-wm0-f44.google.com with SMTP id c131so39240611wmh.0 for <23529@debbugs.gnu.org>; Sun, 11 Sep 2016 23:09:26 -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; bh=4DJsjpJxiIgnmStmxtvlzfjPlIiUY3XQydpin4qlfik=; b=QrMU2cjEbDgZoCevGHGgj/JcMPEZcuRKhC+v0Q6nFmo80yHt9nmvX4i6kCr9UtZjTa OUGothaHV48rYJUg7yE93LIUe0TDNdh0q57OSu5bAQKNuecRHW+iyL+Fsw2HMVXjXnI5 f15lb1tiMucwDG+lap9cF5XXafGJOm8lDAITz7dT/DOxyDWLzmFIcWiaqdTEkoZGw1Jx w/nwNDnbmj22LV5KHVQnA74I+vxvYxnHAgHeVX8SjL7Y2KpEC/FP7FkuLnDGcH3GoKKL qbcVQlczGtHvN6SnHmrA2+DBl68Bz/vDQ6v9XCU8XwpwOJsysC4NSCa4y/0rEC5Iczoe rShQ== 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; bh=4DJsjpJxiIgnmStmxtvlzfjPlIiUY3XQydpin4qlfik=; b=VkYi7/NnRUGNkf7XJkM/vgcZtRHda8bzzAMRn2Cza0d5I6NeGl+iPmMhrsmqtGnkGl AXKcsvsTeXzvDiMFeYB1Y52/szpALYoTQ6rFniWFquRUWIvnoHAqvBIGkHlJV/e8GOc/ Rt0ZXugH7+pFBM20x3RZUAz6kKK9bsIjl6MxTqMjDzkjchfbgEwoxU/OFcsEsvvnaJGz Kqa0p9pTyFHmB7UrETEOkLkxElVodyfpgsIS2CoO813DPvXt+8g8bIH2Uj8jSGfa4yrg l7KAqH8YvP0DywjIX4YfYHulGEWXqNndwS5Pb4MWByDI4Nil3RyVQxrz6de0hnZhlvg9 hnuA== X-Gm-Message-State: AE9vXwM0NxpvxgIonvtHLbr+RURTnZt4uymD8ZF5xrbx7abqAdt9r0xlcvzag0rQmtxy4LN7tLLJGDF+MpdDKQ== X-Received: by 10.28.153.70 with SMTP id b67mr9619818wme.84.1473660560813; Sun, 11 Sep 2016 23:09:20 -0700 (PDT) MIME-Version: 1.0 References: <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> <83wpik8f18.fsf@gnu.org> <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> <83k2ek83b7.fsf@gnu.org> <24612cc1-cb72-511f-7d52-bb62101906ae@cs.ucla.edu> <83fup6bguo.fsf@gnu.org> <83poo9alyc.fsf@gnu.org> <8db7f4c1-8b81-605f-8480-c740d524ccae@gmail.com> In-Reply-To: <8db7f4c1-8b81-605f-8480-c740d524ccae@gmail.com> From: Philipp Stephani Date: Mon, 12 Sep 2016 06:09:10 +0000 Message-ID: Content-Type: multipart/alternative; boundary=001a114b32cc3f740c053c495656 X-Spam-Score: -0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) --001a114b32cc3f740c053c495656 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cl=C3=A9ment Pit--Claudel schrieb am Mo., 12. Sep. = 2016 um 04:59 Uhr: > On 2016-09-11 22:30, Eli Zaretskii wrote: > >> From: Philippe Vaucher > >> Date: Sun, 11 Sep 2016 21:32:51 +0200 > >> Cc: Paul Eggert , Philipp Stephani < > p.stephani2@gmail.com>, 23529@debbugs.gnu.org > >> > >>>> What about disabling randomization for the temacs run? > >>>> > >>>> That is yet another low-level thing to configure, and to get right i= n > new ports. > >>> > >>> We already have that in Emacs, don't we? > >> > >> That is exactly why I made the bug report 23529! > >> > >> Because Emacs does stuffs at build time that requires "high" > >> privileges (like the personality() syscall), one cannot build Emacs in > >> various restricted environments. > >> > >> Disabling randomization is exactly what we should get rid of, at least > >> at build time. > > > > Isn't it the other way around: the first priority is to enable > > randomization and all the other modern techniques for running the > > dumped Emacs? > > I think we want to be able to build the full Emacs in a container; that i= s > without needing, at any point in the process, to disable randomization. = If > I understand correctly, this means that even the process of dumping Emacs > cannot involve disabling randomization. > Yes, that's correct. No step in the build process should have to disable randomization. --001a114b32cc3f740c053c495656 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Cl=C3= =A9ment Pit--Claudel <clement.p= it@gmail.com> schrieb am Mo., 12. Sep. 2016 um 04:59=C2=A0Uhr:
On 2016-09-11 22:30, Eli Zaretskii wrote= :
>> From: Philippe Vaucher <philippe.vaucher@gmail.com= >
>> Date: Sun, 11 Sep 2016 21:32:51 +0200
>> Cc: Paul Eggert <eggert@cs.ucla.edu>, Philipp Stephani = <p.stephani2@gmail.com>, 23529@debbugs.gnu.org
>>
>>>>=C2=A0 =C2=A0 =C2=A0What about disabling randomization for = the temacs run?
>>>>
>>>> That is yet another low-level thing to configure, and to g= et right in new ports.
>>>
>>> We already have that in Emacs, don't we?
>>
>> That is exactly why I made the bug report 23529!
>>
>> Because Emacs does stuffs at build time that requires "high&q= uot;
>> privileges (like the personality() syscall), one cannot build Emac= s in
>> various restricted environments.
>>
>> Disabling randomization is exactly what we should get rid of, at l= east
>> at build time.
>
> Isn't it the other way around: the first priority is to enable
> randomization and all the other modern techniques for running the
> dumped Emacs?

I think we want to be able to build the full Emacs in a container; that is = without needing, at any point in the process, to disable randomization.=C2= =A0 If I understand correctly, this means that even the process of dumping = Emacs cannot involve disabling randomization.

Yes, that's correct. No step in the bu= ild process should have to disable randomization.
--001a114b32cc3f740c053c495656-- From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Philippe Vaucher Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Sep 2016 14:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Philipp Stephani , Paul Eggert , 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147368949511222 (code B ref 23529); Mon, 12 Sep 2016 14:12:02 +0000 Received: (at 23529) by debbugs.gnu.org; 12 Sep 2016 14:11:35 +0000 Received: from localhost ([127.0.0.1]:57760 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjRxL-0002ur-VR for submit@debbugs.gnu.org; Mon, 12 Sep 2016 10:11:35 -0400 Received: from mail-vk0-f46.google.com ([209.85.213.46]:34693) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjRxF-0002uZ-Qg for 23529@debbugs.gnu.org; Mon, 12 Sep 2016 10:11:30 -0400 Received: by mail-vk0-f46.google.com with SMTP id v189so135716294vkv.1 for <23529@debbugs.gnu.org>; Mon, 12 Sep 2016 07:11:25 -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=q6i5gcxQEFFHMQ+sFNHxedI3B1zrZPc3zhTWzAksdgw=; b=pVjuRvlo7qoaedTwiVQOQYq01sEyJ5FScBFS6eR5RBL8dxGnvBMvYxMX7zLjAuJD2p hMlQ2V+iO25cCs7LRDATKb3GKQ9y8A3l/BBg7UOn0qrV8bJPh4mdAmBDuhdyNtCvL1u7 JnCdYc3UlQvVMNlj6h/81C2puKc09BiF5l3iRSfakFiB5BJj5/FWIPW1GZVpcDP4OTEJ 5Fl+TrB25k+K59vv8u3dAVsT7PmBj8NF0USIVHizr/w14kYj1rYBGowbX7MDDay50nGi pIuP8Glhqya9KRABPinRk/zgle6NDR//RGoMDTEU49cLhGUE3sUH5BCf9fNLf477WosJ hHIg== 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=q6i5gcxQEFFHMQ+sFNHxedI3B1zrZPc3zhTWzAksdgw=; b=Er07LjoDGCXwJljMfi5MIYOWzi9eqcgdXzhw4d1fhVnTllKRuHLNI8GqJnU2j1lWKy jOVn4uQJBjN8Xw+NBgPd1lIY6W1r6s3FPb22Vtg/fiUAeBHmMHdRuWWBwlRk+mvQoNR3 lc/AsReWALJhvQlhikHRd+Cu0YyeAUOgkGR0HqhRlgpaVZeqfXbnsM3pgkBYcTSYoWLa 16EFLl+ItkvLz6mrud+jmyUiaPfVlEujA/obVthdN+GSwnmlVC1oZIzq7bBxsWMwPoC5 nYTDfz41B/XNhButYinPBUmoGubzReVuqheoLr7wpg/CRgY673uG6gPLDaIpf+6bsZGL usXw== X-Gm-Message-State: AE9vXwNDIDbLBBPbrAClD3RcG+NnHu8mtuc1MVdjFIdF3DOTefcEUl8OGnV6h8H9e++d48tj4Uv51ADiBcIfHA== X-Received: by 10.31.107.73 with SMTP id g70mr11269752vkc.20.1473689478581; Mon, 12 Sep 2016 07:11:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.44.18 with HTTP; Mon, 12 Sep 2016 07:10:47 -0700 (PDT) In-Reply-To: <83poo9alyc.fsf@gnu.org> References: <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> <83wpik8f18.fsf@gnu.org> <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> <83k2ek83b7.fsf@gnu.org> <24612cc1-cb72-511f-7d52-bb62101906ae@cs.ucla.edu> <83fup6bguo.fsf@gnu.org> <83poo9alyc.fsf@gnu.org> From: Philippe Vaucher Date: Mon, 12 Sep 2016 16:10:47 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Mon, Sep 12, 2016 at 4:30 AM, Eli Zaretskii wrote: >> From: Philippe Vaucher >> Date: Sun, 11 Sep 2016 21:32:51 +0200 >> Cc: Paul Eggert , Philipp Stephani , 23529@debbugs.gnu.org >> >> >> 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? >> >> That is exactly why I made the bug report 23529! >> >> Because Emacs does stuffs at build time that requires "high" >> privileges (like the personality() syscall), one cannot build Emacs in >> various restricted environments. >> >> Disabling randomization is exactly what we should get rid of, at least >> at build time. > > Isn't it the other way around: the first priority is to enable > randomization and all the other modern techniques for running the > dumped Emacs? Now you confuse me... let's start over: I'm saying that we should try to make Emacs build fine wether there is address randomization or not . There should not be "disable ASLR" hacks when building/dumping, like there currently is. Basically, Emacs should not require higher privileges than GCC, which is currently not the case with all the personality() syscalls & friends. Now, maybe I missunderstood you when you said "What about disabling randomization for the temacs run?". I understood that as "Why don't we disable ASLR when temacs run?", which is exactly why Emacs has problem building in restricted environments. Philippe From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Philippe Vaucher Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Sep 2016 14:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Philipp Stephani , Paul Eggert , 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147368993911877 (code B ref 23529); Mon, 12 Sep 2016 14:19:02 +0000 Received: (at 23529) by debbugs.gnu.org; 12 Sep 2016 14:18:59 +0000 Received: from localhost ([127.0.0.1]:57765 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjS4V-00035R-FD for submit@debbugs.gnu.org; Mon, 12 Sep 2016 10:18:59 -0400 Received: from mail-vk0-f49.google.com ([209.85.213.49]:35375) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjS4Q-00035B-3t for 23529@debbugs.gnu.org; Mon, 12 Sep 2016 10:18:53 -0400 Received: by mail-vk0-f49.google.com with SMTP id 16so116935701vko.2 for <23529@debbugs.gnu.org>; Mon, 12 Sep 2016 07:18: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=eJ5KpA2xzdZxQQp3iogGc64DHYAP9hq0i7fXAsearmY=; b=LRlKLm8i4903L8CmITU388gCDCEBDyA79dcIocgUCq3cBMjqukxBbKeY+yJrJqksoM i1SlaN0ciy0eG/q/6N+qT7QCbCBE9ggv3ENXRuZSbK696xnAuJGtEe1iODbohjJGW8Iv CdQWJVqCKMCnxlR2Xm4NLk1TGiXWVu6R+DAnXGSyMkLigfQr/DojpILH7YPLktXr4Nrp d2ClGFzsMq+bcSpKjWKQcApy7LlLKmqAn6Kl5WgcBWE83S9bWledqc6s4JkMFZkK8ZzB cbNc2MrRxtF6CcFg/YFcC7jcOHEdnWKgzlpwZ8W8Vg4UZWLKTWCvYZa9vvvAqQvhmQg5 NaaA== 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=eJ5KpA2xzdZxQQp3iogGc64DHYAP9hq0i7fXAsearmY=; b=d5z4TEDXqdbeP6RWU2oJ7Pv6M2SPXKc8HJGY/MJTCWsaLR/Y1ikmOeGSENc9TY7ghU lUfRp1rVbd+fB1l9SeHLZJ9sbX7lZ2tfOfoPWSbM74S45Ae7BVRyBrj1+R+MEctoz1bj Qv+//UB/Lvz4/5AWL3h8tcCETs/mNDXqDIbMKkqRreojQ6qVzhLfANFkSpkewGndBwV5 u4YcyWpI1xWsYYD6Ig8e7b1hkadnqArD0A2ULa3kntj1VGwJUTgjF5PIZBm+sYlMpXCs F0s+ngPhZEOGF2ejGmMeXzjlsHf8GLoP0xlBT+38+TC8bfSZbKVUhMNO+mJI1LpqC9Fm q51g== X-Gm-Message-State: AE9vXwPqmPtVgLcFn6QPS+J8eFJ2gjVBllukvjROMq1t55BgUy2TIMQOlxXiAxodPJ10PUdHdNyLchR63VBp7w== X-Received: by 10.31.10.133 with SMTP id 127mr12251508vkk.109.1473689922277; Mon, 12 Sep 2016 07:18:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.44.18 with HTTP; Mon, 12 Sep 2016 07:18:11 -0700 (PDT) In-Reply-To: References: <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> <83wpik8f18.fsf@gnu.org> <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> <83k2ek83b7.fsf@gnu.org> <24612cc1-cb72-511f-7d52-bb62101906ae@cs.ucla.edu> <83fup6bguo.fsf@gnu.org> <83poo9alyc.fsf@gnu.org> From: Philippe Vaucher Date: Mon, 12 Sep 2016 16:18:11 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) Interesting links from https://github.com/docker/docker/issues/22801 http://www.openwall.com/lists/musl/2015/02/03/1 https://lwn.net/Articles/673724/ From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Sep 2016 17:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philipp Stephani Cc: 23529@debbugs.gnu.org, clement.pit@gmail.com Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147369988927294 (code B ref 23529); Mon, 12 Sep 2016 17:05:02 +0000 Received: (at 23529) by debbugs.gnu.org; 12 Sep 2016 17:04:49 +0000 Received: from localhost ([127.0.0.1]:57869 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjUf2-00076A-UF for submit@debbugs.gnu.org; Mon, 12 Sep 2016 13:04:49 -0400 Received: from eggs.gnu.org ([208.118.235.92]:54336) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjUf2-00075v-27 for 23529@debbugs.gnu.org; Mon, 12 Sep 2016 13:04:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bjUet-00010J-6C for 23529@debbugs.gnu.org; Mon, 12 Sep 2016 13:04:42 -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.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]:39775) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjUet-0000zv-2u; Mon, 12 Sep 2016 13:04:39 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1880 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bjUer-0006UT-25; Mon, 12 Sep 2016 13:04:37 -0400 Date: Mon, 12 Sep 2016 20:04:39 +0300 Message-Id: <83bmzt9hi0.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Philipp Stephani on Mon, 12 Sep 2016 06:09:10 +0000) References: <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> <83wpik8f18.fsf@gnu.org> <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> <83k2ek83b7.fsf@gnu.org> <24612cc1-cb72-511f-7d52-bb62101906ae@cs.ucla.edu> <83fup6bguo.fsf@gnu.org> <83poo9alyc.fsf@gnu.org> <8db7f4c1-8b81-605f-8480-c740d524ccae@gmail.com> 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.3 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.3 (-------) > From: Philipp Stephani > Date: Mon, 12 Sep 2016 06:09:10 +0000 > > > Isn't it the other way around: the first priority is to enable > > randomization and all the other modern techniques for running the > > dumped Emacs? > > I think we want to be able to build the full Emacs in a container; that is without needing, at any point in the process, to disable randomization. If I understand correctly, this means that even the process of dumping Emacs cannot involve disabling randomization. > > Yes, that's correct. No step in the build process should have to disable randomization. Got it, thanks. However, on second thought, I don't see why this would be an issue. I've mentioned gmalloc as a candidate for an malloc implementation during the temacs run (i.e. during dumping), because gmalloc can be told to use our own sbrk, and that sbrk could allocate memory off an array we define; this might make the job of finding the memory to dump easier. Paul said that gmalloc doesn't work well when ASLR is enabled, but I now think this is not relevant, because we will be allocating from a single contiguous array, which AFAIU is unaffected by ASLR, and also makes those gmalloc problems a non-issue as a side effect. Moreover, if for some reason using gmalloc is not an option, or doesn't really help with this job, that would just make the job of collecting the memory to dump harder, but not too hard. Again, ASLR adds nothing to this picture, as the job of collecting the memory to dump will be based on known pointers to known data structures, and the values of the addresses where these pointers point to are of no importance. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Sep 2016 14:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philippe Vaucher Cc: p.stephani2@gmail.com, eggert@cs.ucla.edu, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147377805412546 (code B ref 23529); Tue, 13 Sep 2016 14:48:02 +0000 Received: (at 23529) by debbugs.gnu.org; 13 Sep 2016 14:47:34 +0000 Received: from localhost ([127.0.0.1]:58814 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjozh-0003GA-TS for submit@debbugs.gnu.org; Tue, 13 Sep 2016 10:47:34 -0400 Received: from eggs.gnu.org ([208.118.235.92]:56233) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjozc-0003Fq-68 for 23529@debbugs.gnu.org; Tue, 13 Sep 2016 10:47:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bjozS-0002sB-K6 for 23529@debbugs.gnu.org; Tue, 13 Sep 2016 10:47:18 -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.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]:58342) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjozS-0002rq-Fz; Tue, 13 Sep 2016 10:47:14 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2562 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bjozR-0003Jb-HE; Tue, 13 Sep 2016 10:47:13 -0400 Date: Tue, 13 Sep 2016 17:47:18 +0300 Message-Id: <83intz97rd.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Philippe Vaucher on Mon, 12 Sep 2016 16:18:11 +0200) References: <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> <83wpik8f18.fsf@gnu.org> <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> <83k2ek83b7.fsf@gnu.org> <24612cc1-cb72-511f-7d52-bb62101906ae@cs.ucla.edu> <83fup6bguo.fsf@gnu.org> <83poo9alyc.fsf@gnu.org> 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.3 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.3 (-------) What about this idea: https://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01049.html To recap: the idea is to dump the dumping (pun intended), and instead load the preloaded packages upon each session start. This currently takes about 5 to 12 sec, depending on the platform and the optimization switches, but a simple optimization brings it down to below 0.5 sec in an optimized build. Further testing indicates that lumping all of the files we preload into a single .elc file reduces the load time even more, so it becomes around 0.1-0.2 sec. That should be short enough to make it negligible, right? This sounds as a much easier and low-risk approach. Its significant advantage is that it doesn't require any serious changes in the low-level infrastructure -- no need for generating C code or dump data records as part of DEFUN, defsubr, and staticpro, no need to hunt for, dump, and restore global variables that hold Lisp objects, no dependencies on external tools, etc. Almost everything in support of this method, like the ability to redirect results of compiling several source files into a single .elc file, can be done in Lisp, mainly in loadup.el, plus some Makefile changes in the last stages of the build process. A much simpler design and higher-level implementation mean more people could be involved in working on this, testing, and debugging, instead of relying on a couple of "usual suspects" who are overloaded anyway. Having a single .elc file provides a nice bonus of being able to run Emacs even if the Lisp files are not available. And re-dumping can be supported with almost no effort. If this idea is accepted, the first question to ask is whether we still need pure storage on modern platforms. If we do, find_string_data_in_pure will have to be sped up by using a hash table or some such. If pure storage is not needed, purecopy can be a no-op and find_string_data_in_pure should simply go away, which is of course much easier. Comments? From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Philippe Vaucher Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Sep 2016 15:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Philipp Stephani , Paul Eggert , 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147378012515667 (code B ref 23529); Tue, 13 Sep 2016 15:23:01 +0000 Received: (at 23529) by debbugs.gnu.org; 13 Sep 2016 15:22:05 +0000 Received: from localhost ([127.0.0.1]:58835 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjpX6-00044H-U4 for submit@debbugs.gnu.org; Tue, 13 Sep 2016 11:22:05 -0400 Received: from mail-vk0-f49.google.com ([209.85.213.49]:36454) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjpX1-00043z-3B for 23529@debbugs.gnu.org; Tue, 13 Sep 2016 11:21:59 -0400 Received: by mail-vk0-f49.google.com with SMTP id m62so129311408vkd.3 for <23529@debbugs.gnu.org>; Tue, 13 Sep 2016 08:21:55 -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=3lXwiO3/WEFgJvP41iM/1Pgd0qEmRmwnBODC8j9akf4=; b=t8wRsDUVCqPpo8uK8gb9Px0SbnpHXO3EP9y+HmGZNgF2CptV+tznZCj3mXAYTKjWBA VEuEOy4mT395WJz4yjwZE6aVrlvdCVFapoqRdp6KSCiS9uSlhWrnrJG4e/MYZoup7buT 6nd9Cf+HsqkS9Vq0wt9+eM7yQw339taTt3ZdHfVoFFDrMCswHQRK5KCbp0PDYU8HAUbP ZFDPAvyLgfyDRC0/lxx4aDPd8PEJsNQrpCsaWZm5u3sKT/Ooew1ZedcC+l9UjL5SKQNu HTcNNs/9qwAFdp+KltsVwtDngnqYC+wJ2qe5pDYc/U+NNl1zvIccr0krPrg4PI1Fgt3u +inw== 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=3lXwiO3/WEFgJvP41iM/1Pgd0qEmRmwnBODC8j9akf4=; b=MHqDbolZu/lqllI5hPXxyOTVY9u0HRAhfBShhnCcpXzVK2fxTkp6qLYHQ6vaK4kmE/ gtSsJzb1ZnEWkrsH8trUrzL0rp6F81vZ75b1kPPZqkMpLVth8XYS+IYaKLREiUYwniDk 4WqNryVGvuMAuEXqiHXjIYitqtXMKVxLcRZuXEXq+/kIodtWTA1l7t3dGnMuQDTEAb/x m7A4HVJA1nYrwzRNM6YeTmw73Jml6+0EQbpqeOmR4wUPU79TmRMcR/aniddgX1qB4pG7 fyJ++Y9ALfTQQYh75bvnDXbEthcZkCKH196mZlietgG39JemLr0iWxNGGUX7q4SCFItt vy7A== X-Gm-Message-State: AE9vXwPr/1CoYiM59YwFicbRS96p2SjTnaWJYpvhstaYVIykIqtXs4B3Ly2GZ3d1iyItEzs+khMjvI20isoKpQ== X-Received: by 10.31.188.144 with SMTP id m138mr1333204vkf.84.1473780109743; Tue, 13 Sep 2016 08:21:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.44.18 with HTTP; Tue, 13 Sep 2016 08:21:18 -0700 (PDT) In-Reply-To: <83intz97rd.fsf@gnu.org> References: <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> <83wpik8f18.fsf@gnu.org> <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> <83k2ek83b7.fsf@gnu.org> <24612cc1-cb72-511f-7d52-bb62101906ae@cs.ucla.edu> <83fup6bguo.fsf@gnu.org> <83poo9alyc.fsf@gnu.org> <83intz97rd.fsf@gnu.org> From: Philippe Vaucher Date: Tue, 13 Sep 2016 17:21:18 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) > What about this idea: > > https://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01049.html > > To recap: the idea is to dump the dumping (pun intended), and instead > load the preloaded packages upon each session start. I'm all for removing the dumping entirely, because I never use it (using use-package is fast enough for me). I thought you wanted to keep the dumping feature tho, maybe I missunderstood you (again) :-) Philippe From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Sep 2016 15:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Philippe Vaucher Cc: p.stephani2@gmail.com, 23529@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147378193118310 (code B ref 23529); Tue, 13 Sep 2016 15:53:02 +0000 Received: (at 23529) by debbugs.gnu.org; 13 Sep 2016 15:52:11 +0000 Received: from localhost ([127.0.0.1]:58841 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjq0D-0004lB-L2 for submit@debbugs.gnu.org; Tue, 13 Sep 2016 11:52:11 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:54708) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjq06-0004ka-Ik for 23529@debbugs.gnu.org; Tue, 13 Sep 2016 11:52:04 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 83445161177; Tue, 13 Sep 2016 08:51:51 -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 DaWeQOLmBsFC; Tue, 13 Sep 2016 08:51:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C49D416117E; Tue, 13 Sep 2016 08:51:50 -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 KSu1OhdHPshA; Tue, 13 Sep 2016 08:51:50 -0700 (PDT) Received: from [192.168.1.9] (unknown [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id A0CBA161177; Tue, 13 Sep 2016 08:51:50 -0700 (PDT) References: <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> <83wpik8f18.fsf@gnu.org> <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> <83k2ek83b7.fsf@gnu.org> <24612cc1-cb72-511f-7d52-bb62101906ae@cs.ucla.edu> <83fup6bguo.fsf@gnu.org> <83poo9alyc.fsf@gnu.org> <83intz97rd.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <0d7013e9-fbdf-ebb1-7361-fe8637079cff@cs.ucla.edu> Date: Tue, 13 Sep 2016 08:51:47 -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: <83intz97rd.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Eli Zaretskii wrote: > the idea is to dump the dumping (pun intended), and instead > load the preloaded packages upon each session start. This approach could well work. It addresses the portability concerns with= =20 malloc, as it means we can just use the system malloc. If it has acceptab= le=20 performance and its bugs can be fixed, it would be a good way to go. My main worry is performance. On the desktop that I'm typing this message= on,=20 emacs -Q takes about 40 ms to start up in batch mode, about 90 ms in a te= rminal,=20 and about 300 ms on a graphical display. These are the sorts of times tha= t I'd=20 like to see with the proposed approach too. (This desktop is using a 4-ye= ar-old=20 Xeon E3-1225 V2 CPU, and Emacs is stored on flash and typically cached in= RAM.) By "dump the dumping" I assume you mean withdraw the traditional dump-ema= cs=20 function. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Sep 2016 15:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philippe Vaucher Cc: p.stephani2@gmail.com, eggert@cs.ucla.edu, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147378211818591 (code B ref 23529); Tue, 13 Sep 2016 15:56:02 +0000 Received: (at 23529) by debbugs.gnu.org; 13 Sep 2016 15:55:18 +0000 Received: from localhost ([127.0.0.1]:58846 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjq3G-0004pj-M9 for submit@debbugs.gnu.org; Tue, 13 Sep 2016 11:55:18 -0400 Received: from eggs.gnu.org ([208.118.235.92]:44604) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjq3B-0004pQ-U2 for 23529@debbugs.gnu.org; Tue, 13 Sep 2016 11:55:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bjq33-0005M4-KX for 23529@debbugs.gnu.org; Tue, 13 Sep 2016 11:55: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=-4.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]:59333) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjq33-0005KZ-Hl; Tue, 13 Sep 2016 11:55:01 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3005 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bjq32-0005sc-DO; Tue, 13 Sep 2016 11:55:00 -0400 Date: Tue, 13 Sep 2016 18:55:05 +0300 Message-Id: <83h99j94me.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Philippe Vaucher on Tue, 13 Sep 2016 17:21:18 +0200) References: <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> <83wpik8f18.fsf@gnu.org> <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> <83k2ek83b7.fsf@gnu.org> <24612cc1-cb72-511f-7d52-bb62101906ae@cs.ucla.edu> <83fup6bguo.fsf@gnu.org> <83poo9alyc.fsf@gnu.org> <83intz97rd.fsf@gnu.org> 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.3 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.3 (-------) > From: Philippe Vaucher > Date: Tue, 13 Sep 2016 17:21:18 +0200 > Cc: Paul Eggert , Philipp Stephani , 23529@debbugs.gnu.org > > I thought you wanted to keep the dumping feature tho, maybe I > missunderstood you (again) :-) I want to keep the ability of users to add more packages to the stuff that is automatically available at startup. From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Sep 2016 19:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert Cc: philippe.vaucher@gmail.com, p.stephani2@gmail.com, 23529@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.14737947434854 (code B ref 23529); Tue, 13 Sep 2016 19:26:02 +0000 Received: (at 23529) by debbugs.gnu.org; 13 Sep 2016 19:25:43 +0000 Received: from localhost ([127.0.0.1]:58916 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjtKw-0001GE-MJ for submit@debbugs.gnu.org; Tue, 13 Sep 2016 15:25:42 -0400 Received: from eggs.gnu.org ([208.118.235.92]:52840) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjtKu-0001G2-T9 for 23529@debbugs.gnu.org; Tue, 13 Sep 2016 15:25:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bjtKm-0007Ox-L1 for 23529@debbugs.gnu.org; Tue, 13 Sep 2016 15:25:35 -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.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]:35082) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjtKm-0007Ob-De; Tue, 13 Sep 2016 15:25:32 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3177 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bjtKV-0000gW-Pf; Tue, 13 Sep 2016 15:25:30 -0400 Date: Tue, 13 Sep 2016 22:24:42 +0300 Message-Id: <83eg4n8ux1.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <0d7013e9-fbdf-ebb1-7361-fe8637079cff@cs.ucla.edu> (message from Paul Eggert on Tue, 13 Sep 2016 08:51:47 -0700) References: <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> <83wpik8f18.fsf@gnu.org> <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> <83k2ek83b7.fsf@gnu.org> <24612cc1-cb72-511f-7d52-bb62101906ae@cs.ucla.edu> <83fup6bguo.fsf@gnu.org> <83poo9alyc.fsf@gnu.org> <83intz97rd.fsf@gnu.org> <0d7013e9-fbdf-ebb1-7361-fe8637079cff@cs.ucla.edu> 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.3 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.3 (-------) > Cc: p.stephani2@gmail.com, 23529@debbugs.gnu.org > From: Paul Eggert > Date: Tue, 13 Sep 2016 08:51:47 -0700 > > Eli Zaretskii wrote: > > the idea is to dump the dumping (pun intended), and instead > > load the preloaded packages upon each session start. > > This approach could well work. It addresses the portability concerns with > malloc, as it means we can just use the system malloc. If it has acceptable > performance and its bugs can be fixed, it would be a good way to go. That's the goal, yes. > My main worry is performance. On the desktop that I'm typing this message on, > emacs -Q takes about 40 ms to start up in batch mode, about 90 ms in a terminal, > and about 300 ms on a graphical display. These are the sorts of times that I'd > like to see with the proposed approach too. (This desktop is using a 4-year-old > Xeon E3-1225 V2 CPU, and Emacs is stored on flash and typically cached in RAM.) I don't see why we couldn't keep these times, or come close, if your disk is flash memory. I got 0.2 sec with a real disk, in a 32-bit build with wide ints, and that was without any serious attempt to find the hot spots and optimize them. > By "dump the dumping" I assume you mean withdraw the traditional dump-emacs > function. Yes. Instead, there should be mostly Lisp code to produce a single .elc file for all the preloaded stuff, and calculate values of some variables that can only be recorded at build time (like source-directory, for example). From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues References: In-Reply-To: Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Sep 2019 04:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philippe Vaucher Cc: 23529@debbugs.gnu.org, 13964@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.15684347426895 (code B ref 23529); Sat, 14 Sep 2019 04:20:02 +0000 Received: (at 23529) by debbugs.gnu.org; 14 Sep 2019 04:19:02 +0000 Received: from localhost ([127.0.0.1]:45739 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i8zWY-0001n9-AY for submit@debbugs.gnu.org; Sat, 14 Sep 2019 00:19:02 -0400 Received: from mail-pf1-f180.google.com ([209.85.210.180]:41736) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i8zWW-0001mb-8Z; Sat, 14 Sep 2019 00:19:01 -0400 Received: by mail-pf1-f180.google.com with SMTP id b13so19276072pfo.8; Fri, 13 Sep 2019 21:19:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=mllxPI5ob5YZCcTz8jinIvTVRQRQn1G3K2pTC+w6C8M=; b=ojYGJ6lM56ggWWK3PlHfdpEskd5F4PiMXgIF/5h4N++6I2gISgOEcMI+mf3HeSQvMi ItJqvP4GtXlkoNoaMDWZzTWcQWqUCMwg3hJx1+GJyMKBQ0Hz5LPhy+D0EgxkvdI4jpIG mRKzrQRrTI/Oi5KWXq1pveCe4TEcoS4YqIbqWoaSQkUSd5lx/gZPq0RVKmKKvH5cJ6mn KRKpQjLgWq/cvl2VpBbO9T6nVfokvqa9RM4MU4YIevxz1WE/t4NVAaEvoSefOxr3CsVk rBpvUXyd5PTHwaiAaIr7/Ub00dN4QQJoLwKTVym6ETGxVwe2nrhWj0ejp53HNCCO2LQT Vh6g== X-Gm-Message-State: APjAAAX5yVQ4MoQBNQ9gr6Tt3e9QgqAulKEnWis5EbG2q/yM25lGES9O MlIPY13WCxBjZwYQtJzS1Zbn2qEkd5F5vfkyg0c= X-Google-Smtp-Source: APXvYqxNufz1od9BMVk8xfK6m/wNBxv9WGXMNswgjRemvCzchG4UxpLXJnuZ4t+E93JOgV18ZdgbmIuXdgATD1Z11C8= X-Received: by 2002:aa7:8156:: with SMTP id d22mr32997602pfn.190.1568434734365; Fri, 13 Sep 2019 21:18:54 -0700 (PDT) MIME-Version: 1.0 From: Stefan Kangas Date: Sat, 14 Sep 2019 06:18:43 +0200 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Philippe Vaucher writes: > 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' Is this still an issue with Emacs 27.0.50 (current master branch)? etc/NEWS says: ** Emacs now uses a "portable dumper" instead of unexec. This improves compatibility with memory allocation on modern systems, and in particular better supports the Address Space Layout Randomization (ASLR) feature, a security technique used by most modern operating systems. Thanks, Stefan Kangas From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Philippe Vaucher Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Sep 2019 08:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Kangas Cc: 23529@debbugs.gnu.org, 13964@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.15684511522715 (code B ref 23529); Sat, 14 Sep 2019 08:53:02 +0000 Received: (at 23529) by debbugs.gnu.org; 14 Sep 2019 08:52:32 +0000 Received: from localhost ([127.0.0.1]:45860 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i93nD-0000hi-R1 for submit@debbugs.gnu.org; Sat, 14 Sep 2019 04:52:31 -0400 Received: from mail-lj1-f171.google.com ([209.85.208.171]:38050) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i93nC-0000hS-1L; Sat, 14 Sep 2019 04:52:30 -0400 Received: by mail-lj1-f171.google.com with SMTP id y23so28923682ljn.5; Sat, 14 Sep 2019 01:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K1zUR+1mPxsrtWlqRnvvsukEnp1FStj0xrTYN01bAl4=; b=GLE92pLLjcnRk+MzCO39sTvUMYWcLm+L72n7LrOn3ATukQwA7PeRpyp/+rDkkPLNrL i91MTlUFjzsn9eEbhozqggF/b7SdfKt5QgfOvy/HfCGi0Qn6s4dVmtchRcym/LGZ9XZO XxiHn5BL31EwX1b3x56dZrcAaes9YDVuGYs8vdCjLXe5kgkBcEQiMSFn65VZriUPONKl qoU5NQn4EGtQQPWwaaYPPKOh0OH7CVKv3HUeExSYxgn/xA1lmKquedefaUh3TzHACRw4 d6NyrvMcXAD7Vk5awy/lAI4DBz1FaPdHLkWllK1SlRvp7zgCKVXw5vUJi6ZNfm4FtRAO jZhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K1zUR+1mPxsrtWlqRnvvsukEnp1FStj0xrTYN01bAl4=; b=MF612YJgEexm2NLs3eXoKYN1FEpHxeZtakz8aDoR6N8lln8RZJUAX9M9CIeVrv1lI3 P73y+wE+4ih1isUzfea36ft8ANIREL+iT2GY2OSPq+dw6B5O1eriiAViwbR7TB5LlTLi C0LjuUU0g/OraubRuJ7lVjyKfiJ+72hAKpuk7P52r78BPWeSBYMcdpduhnh5nqVnYZRZ icSPRR5xryxVi1uBzSKEDNfvbxE5J6TWzjiabC5xMGJRPtFbHUC3EvZ36qyW80uCi4VM jUNchoHYRdsPYW+kLrsi7+Xmh4LfJETDFA4tZm7NdoGUsH1KjXi3MXL9M0P+0Kk6NxDb sRgg== X-Gm-Message-State: APjAAAXr95x4J9zCQt3fTPxypmDH4yItxtAJXwI1xbLtQRwFmutGs1w1 EwHk6QNJPaV06PjmU8Ytha/lX3Gt4t0rEJD6MPU3Kg== X-Google-Smtp-Source: APXvYqyvc1RWPQuPAxC9SW2h7y2GyrNxtcTI4y7I9PmuA6fhvlIZtsuBibOe2hE9WoVeQWb0Sj5wwC0fSqAMcQKyEG4= X-Received: by 2002:a2e:3a0e:: with SMTP id h14mr11434039lja.161.1568451143926; Sat, 14 Sep 2019 01:52:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Philippe Vaucher Date: Sat, 14 Sep 2019 10:52:11 +0200 Message-ID: Content-Type: multipart/alternative; boundary="0000000000004806c505927f7d3e" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000004806c505927f7d3e Content-Type: text/plain; charset="UTF-8" > > Is this still an issue with Emacs 27.0.50 (current master branch)? > No, this is indeed fixed in master. This ticket can thus be closes. Regards, Philippe > --0000000000004806c505927f7d3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Is this still an issue with Emacs 27.0.50 (current master branch)?

No,= this is indeed fixed in master.

This ticket can thus be closes.

=
Regards,
Philippe
--0000000000004806c505927f7d3e-- From unknown Sun Aug 17 04:21:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23529: Request for fixing randomize_va_space build issues Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Sep 2019 10:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philippe Vaucher Cc: 23529@debbugs.gnu.org, 13964@debbugs.gnu.org Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.156845759612780 (code B ref 23529); Sat, 14 Sep 2019 10:40:02 +0000 Received: (at 23529) by debbugs.gnu.org; 14 Sep 2019 10:39:56 +0000 Received: from localhost ([127.0.0.1]:45906 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i95T8-0003Jz-FZ for submit@debbugs.gnu.org; Sat, 14 Sep 2019 06:39:56 -0400 Received: from mail-pf1-f178.google.com ([209.85.210.178]:32844) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i95T5-0003JZ-S0; Sat, 14 Sep 2019 06:39:52 -0400 Received: by mail-pf1-f178.google.com with SMTP id q10so19663448pfl.0; Sat, 14 Sep 2019 03:39:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eo8lHotzwOdIbw0K+rqPQI8yux26BXdw8acW/L38+vk=; b=P1BUs0/QTsZ+9fp/WQnvuaF9IqP1In0dxWSrpwZgOIQP/J4ZRsXWQw+DYBFI7CrEoV kRCYDMZ0ZeIstgBasu76+jpHWpk15MLbCNZVSUMnwzucc3iolQX4AMRblAaAtvllVuOt HTEi6zPpFNiFfOFaz59wPpwLE/UXLPirfmw5qiNGB3ZwT9mHCBP15/NOZRtSB4va5K1l g8CsY/wn1vOA1GG5jD4Zs19seXEKhNofmv85yDPDemU6nebtQ0KHgXa6lPyA7OXZE7hH Se/pFXICf0ivXQtHAzXbb5yM5/wFCGsR/5oh4NzsgG2j8Ig2GeORgl/ocTkGaC8Id5dN SmAQ== X-Gm-Message-State: APjAAAUqqflKS+7FrezZHzp1sp3qcl1kB8DRUcehV+cYZndK6BjSiLsJ eVyJfM3AVCK/uUGrU5LvcWylaf5tYxj31/Jn75c= X-Google-Smtp-Source: APXvYqxtR+JM1F/p/7g6rCWHDnglqc/Y4lhpkwcWO+SIji4lbqZXfjxyug51FE01KvmB53nqtGmFqMo2/TKR1h14HR0= X-Received: by 2002:aa7:8005:: with SMTP id j5mr61108143pfi.50.1568457586048; Sat, 14 Sep 2019 03:39:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Stefan Kangas Date: Sat, 14 Sep 2019 12:39:34 +0200 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tags 23529 fixed close 23529 27.1 quit Philippe Vaucher writes: >> Is this still an issue with Emacs 27.0.50 (current master branch)? > > No, this is indeed fixed in master. > > This ticket can thus be closes. Thanks. I'm therefore closing this bug. Best regards, Stefan Kangas