From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#23529: Request for fixing randomize_va_space build issues Date: Sun, 11 Sep 2016 18:23:27 +0300 Message-ID: <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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1473607469 7897 195.159.176.226 (11 Sep 2016 15:24:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Sep 2016 15:24:29 +0000 (UTC) Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 11 17:24:21 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bj6cF-00017z-7A for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 Sep 2016 17:24:19 +0200 Original-Received: from localhost ([::1]:38019 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bj6cD-0001bG-BS for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 Sep 2016 11:24:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43121) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bj6c2-0001b9-OP for bug-gnu-emacs@gnu.org; Sun, 11 Sep 2016 11:24:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bj6by-0002WF-J7 for bug-gnu-emacs@gnu.org; Sun, 11 Sep 2016 11:24:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58844) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bj6by-0002WB-FE for bug-gnu-emacs@gnu.org; Sun, 11 Sep 2016 11:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bj6by-0000z7-9p for bug-gnu-emacs@gnu.org; Sun, 11 Sep 2016 11:24:02 -0400 X-Loop: help-debbugs@gnu.org 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: Original-Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.14736074193757 (code B ref 23529); Sun, 11 Sep 2016 15:24:02 +0000 Original-Received: (at 23529) by debbugs.gnu.org; 11 Sep 2016 15:23:39 +0000 Original-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 Original-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 Original-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 Original-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 Original-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 In-reply-to: <24612cc1-cb72-511f-7d52-bb62101906ae@cs.ucla.edu> (message from Paul Eggert on Sat, 10 Sep 2016 16:01:28 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:123172 Archived-At: > 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.