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: Fri, 09 Sep 2016 21:45:58 +0300 Message-ID: <83eg4sap3t.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> <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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1473446847 4727 195.159.176.226 (9 Sep 2016 18:47:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Sep 2016 18:47:27 +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 Fri Sep 09 20:47:23 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 1biQpc-0000Og-W2 for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Sep 2016 20:47:21 +0200 Original-Received: from localhost ([::1]:59698 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biQpa-0003dW-Pu for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Sep 2016 14:47:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34599) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biQpP-0003b8-ON for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 14:47:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1biQpK-0005nu-Kn for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 14:47:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57164) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biQpK-0005np-Gl for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 14:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1biQpK-0006GZ-BU for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 14:47: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: 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: Original-Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147344679324044 (code B ref 23529); Fri, 09 Sep 2016 18:47:02 +0000 Original-Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 18:46:33 +0000 Original-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 Original-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 Original-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 Original-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 Original-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 In-reply-to: (message from Paul Eggert on Fri, 9 Sep 2016 09:16:39 -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:123120 Archived-At: > 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.