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: Fri, 9 Sep 2016 09:16:39 -0700 Organization: UCLA Computer Science Department Message-ID: 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1473437846 20537 195.159.176.226 (9 Sep 2016 16:17:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Sep 2016 16:17:26 +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 Fri Sep 09 18:17:22 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 1biOUQ-0004Wq-Ad for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Sep 2016 18:17:18 +0200 Original-Received: from localhost ([::1]:58938 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biOUO-0008JJ-Cc for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Sep 2016 12:17:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51549) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biOUE-0008HA-UV for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 12:17:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1biOUA-0004Fj-KO for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 12:17:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57102) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biOUA-0004Ff-Gh for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 12:17:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1biOU9-0007mJ-TH for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 12:17:01 -0400 X-Loop: help-debbugs@gnu.org 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: Original-Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147343781029877 (code B ref 23529); Fri, 09 Sep 2016 16:17:01 +0000 Original-Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 16:16:50 +0000 Original-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 Original-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 Original-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) 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 S11q7aGh_WmQ; Fri, 9 Sep 2016 09:16:40 -0700 (PDT) Original-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 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 y49YHMnqr6Qs; Fri, 9 Sep 2016 09:16:40 -0700 (PDT) Original-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) In-Reply-To: <838tv18mnj.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:123112 Archived-At: 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.