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 12:59:16 -0700 Organization: UCLA Computer Science Department Message-ID: <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> 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> <83eg4sap3t.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 1473451224 27902 195.159.176.226 (9 Sep 2016 20:00:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Sep 2016 20:00:24 +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 22:00:20 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 1biRyE-0006aq-1r for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Sep 2016 22:00:18 +0200 Original-Received: from localhost ([::1]:59964 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biRyC-0003SM-1V for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Sep 2016 16:00:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49958) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biRy5-0003Ou-9u for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 16:00:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1biRxz-0005Fc-C6 for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 16:00:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57193) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biRxz-0005FX-A4 for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 16:00:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1biRxz-0008Dj-4P for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2016 16:00:03 -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 20:00:03 +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.147345116531522 (code B ref 23529); Fri, 09 Sep 2016 20:00:03 +0000 Original-Received: (at 23529) by debbugs.gnu.org; 9 Sep 2016 19:59:25 +0000 Original-Received: from localhost ([127.0.0.1]:54905 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biRxM-0008CM-Ps for submit@debbugs.gnu.org; Fri, 09 Sep 2016 15:59:24 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:33922) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biRxL-0008C4-EC for 23529@debbugs.gnu.org; Fri, 09 Sep 2016 15:59:24 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9A0B116120B; Fri, 9 Sep 2016 12:59:17 -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 niIdR9flfIBN; Fri, 9 Sep 2016 12:59:16 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id BEF79161222; Fri, 9 Sep 2016 12:59:16 -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 syunJbxLs4OV; Fri, 9 Sep 2016 12:59:16 -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 A4BA016120B; Fri, 9 Sep 2016 12:59:16 -0700 (PDT) In-Reply-To: <83eg4sap3t.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:123124 Archived-At: On 09/09/2016 11:45 AM, Eli Zaretskii wrote: > 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. Of course. But it's not trivial to fix them. It can be done, but it will take code that will be hard to maintain portably. > gmalloc is already implemented Yes, and its problems are prompting this discussion. gmalloc was a fine design for the 1980s but is not now. > 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). The sbrk model is becoming less and less plausible. > If not, gmalloc > will be good enough for the temacs run; emacs will of course use the > normal libc allocators. This would give up on redumping, no? Plus, it assumes sbrk, which is backward-looking. POSIX has withdrawn support for sbrk and there is movement to deprecate it in C libraries due to security/robustness concerns. This is something we should encourage, not run away from. > 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. It can be distributed between different "blocks", because we can tell the compiler and linker the data structure. Here's a quick example with two small "blocks" dX and dY (the actual code would differ, this is just a proof of concept): /* Simplified version of lisp.h. */ #include typedef intptr_t Lisp_Object; enum { Lisp_Int0 = 2, Lisp_Cons = 3 /* ... */}; #define make_number(n) (((n) << 2) + Lisp_Int0) #define TAG_PTR(tag, ptr) ((intptr_t) (ptr) + (tag)) #define Qnil ((Lisp_Object) 0) struct Lisp_Cons { Lisp_Object car, cdr; }; /* Define a statically-allocated pair x that is equal to (10). */ struct Lisp_Cons dX = { make_number (10), Qnil }; #define x TAG_PTR (Lisp_Cons, &dX) /* Use x to build a statically-allocated list y that is equal to (5 10). */ struct Lisp_Cons dY = { make_number (5), x }; #define y TAG_PTR (Lisp_Cons, &dY) > 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. No, this sort of thing is something that compilers and linkers do all the time.