From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#23529: Request for fixing randomize_va_space build issues Date: Sat, 10 Sep 2016 00:52:33 -0700 Organization: UCLA Computer Science Department Message-ID: <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1473494010 6681 195.159.176.226 (10 Sep 2016 07:53:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 10 Sep 2016 07:53:30 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 10 09:53:24 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 1bid69-0008Nn-Ez for geb-bug-gnu-emacs@m.gmane.org; Sat, 10 Sep 2016 09:53:13 +0200 Original-Received: from localhost ([::1]:33529 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bid67-0005HP-Bx for geb-bug-gnu-emacs@m.gmane.org; Sat, 10 Sep 2016 03:53:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60668) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bid61-0005HK-Kp for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2016 03:53:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bid5y-0006Pr-Fv for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2016 03:53:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57402) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bid5y-0006Pn-Cz for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2016 03:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bid5y-0001n3-73 for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2016 03:53:02 -0400 X-Loop: help-debbugs@gnu.org 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: Original-Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.14734939676861 (code B ref 23529); Sat, 10 Sep 2016 07:53:02 +0000 Original-Received: (at 23529) by debbugs.gnu.org; 10 Sep 2016 07:52:47 +0000 Original-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 Original-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 Original-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) Original-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) Original-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 Original-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) Original-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) In-Reply-To: <83wpik8f18.fsf@gnu.org> 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:123139 Archived-At: 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.