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 01:54:07 -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> 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 1473411374 26914 195.159.176.226 (9 Sep 2016 08:56:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Sep 2016 08:56:14 +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 10:56:10 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 1biHbV-0006VI-1O for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Sep 2016 10:56:09 +0200 Original-Received: from localhost ([::1]:56667 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biHbT-0005Qf-5q for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Sep 2016 04:56:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59405) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biHaS-0004kH-Mf for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 04:55:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1biHaQ-0002QK-Qn for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 04:55:03 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56476) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biHaQ-0002QB-Nw for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 04:55:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1biHaQ-0001mC-Cc for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 04:55: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: Fri, 09 Sep 2016 08:55: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.14734112576771 (code B ref 23529); Fri, 09 Sep 2016 08:55:02 +0000 Original-Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 08:54:17 +0000 Original-Received: from localhost ([127.0.0.1]:54188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biHZg-0001l8-Ov for submit@debbugs.gnu.org; Fri, 09 Sep 2016 04:54:16 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:43242) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biHZf-0001kw-4X for 23529@debbugs.gnu.org; Fri, 09 Sep 2016 04:54:15 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5195D161222; Fri, 9 Sep 2016 01:54:08 -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 Wt7-ViVr5R-d; Fri, 9 Sep 2016 01:54:07 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 793FC161223; Fri, 9 Sep 2016 01:54:07 -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 5t3okRExyvRt; Fri, 9 Sep 2016 01:54:07 -0700 (PDT) Original-Received: from [192.168.1.9] (unknown [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 544B1161222; Fri, 9 Sep 2016 01:54:07 -0700 (PDT) In-Reply-To: <83d1kd8qb7.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:123105 Archived-At: Eli Zaretskii wrote: > Lisp objects are referenced through the obarray Sure, but they are also referenced in many other ways. The obarray is jus= t one=20 corner of this. >> Sure, but that's true of any dumping method. > > Writing out the dumped data is almost trivial Not really. Not nowadays. >> The advantage of dumping to C code is that the compiler and linker >> will deserialize it for you. > > That's true, but I think you pay much more in the serialization phase. That's fine. Serialization is rare, typically just when Emacs is built.=20 Deserialization is much more common, typically whenever Emacs starts up. = So it=20 can be a win to speed up and simplify deserialization at the expense of=20 serialization. > the compiler and the linker were not meant for these jobs I don't see why today's compilers and linkers wouldn't be up to these job= s.=20 Emacs is not that large by today's standards. The proof of that will be i= n the=20 pudding, no? > writing the dumped data and then reading it with fixups is > something we can do ourselves without relying on any external > technologies which need to be bent to our needs. I don't think so. We need to rely on and/or work around properties of add= ress=20 randomization which will be platform-dependent. It will be tempting to do= the=20 job poorly, and lose any reliability and/or security benefits of randomiz= ation=20 that we might otherwise get for free. Letting the compiler and linker do = this=20 work for us will save us work in the long run. > As the number of people who are able to futz with Emacs > internals at this depth continues to dwindle, This is exactly why we should let the compiler- and linker-writers do thi= s work=20 for us.