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: Sat, 10 Sep 2016 13:19:40 +0300 Message-ID: <83k2ek83b7.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1473502894 15660 195.159.176.226 (10 Sep 2016 10:21:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 10 Sep 2016 10:21:34 +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 Sat Sep 10 12:21:30 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 1bifPS-0002IX-Gh for geb-bug-gnu-emacs@m.gmane.org; Sat, 10 Sep 2016 12:21:18 +0200 Original-Received: from localhost ([::1]:33878 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bifPQ-00039N-FX for geb-bug-gnu-emacs@m.gmane.org; Sat, 10 Sep 2016 06:21:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52536) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bifPI-000394-Fc for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2016 06:21:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bifPC-0007u2-TR for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2016 06:21:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57444) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bifPC-0007tx-PX for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2016 06:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bifPC-0006rR-H1 for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2016 06:21: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: 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: Original-Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147350280226269 (code B ref 23529); Sat, 10 Sep 2016 10:21:02 +0000 Original-Received: (at 23529) by debbugs.gnu.org; 10 Sep 2016 10:20:02 +0000 Original-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 Original-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 Original-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 Original-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 Original-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 In-reply-to: <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> (message from Paul Eggert on Sat, 10 Sep 2016 00:52:33 -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:123142 Archived-At: > 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.