From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.bugs Subject: bug#22086: 25.1.50; [PATCH] Integrate the musl hybrid malloc patch for elf systems Date: Mon, 21 Dec 2015 12:58:37 -0800 Message-ID: <4AD10C14-6C14-40E0-A67E-B7919D020B37@dancol.org> References: <85poynxvgy.fsf@iznogoud.viz> <567120C0.6080803@cs.ucla.edu> <85h9jhdxl2.fsf@iznogoud.viz> <56772CB2.8060004@cs.ucla.edu> <567773F4.60000@cornell.edu> <20151221040628.GW238@brightrain.aerifal.cx> <56785C4E.1060202@dancol.org> <20151221204913.GY238@brightrain.aerifal.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1450731567 28341 80.91.229.3 (21 Dec 2015 20:59:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Dec 2015 20:59:27 +0000 (UTC) Cc: Wolfgang Jenkner , 22086@debbugs.gnu.org, Paul Eggert To: Rich Felker Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 21 21:59:12 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aB7Y0-0007ab-7i for geb-bug-gnu-emacs@m.gmane.org; Mon, 21 Dec 2015 21:59:12 +0100 Original-Received: from localhost ([::1]:47247 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aB7Xz-0002Br-De for geb-bug-gnu-emacs@m.gmane.org; Mon, 21 Dec 2015 15:59:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54367) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aB7Xw-0002Bk-0a for bug-gnu-emacs@gnu.org; Mon, 21 Dec 2015 15:59:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aB7Xr-0005O7-17 for bug-gnu-emacs@gnu.org; Mon, 21 Dec 2015 15:59:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51539) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aB7Xq-0005O3-OX for bug-gnu-emacs@gnu.org; Mon, 21 Dec 2015 15:59:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aB7Xq-0000Vn-E6 for bug-gnu-emacs@gnu.org; Mon, 21 Dec 2015 15:59:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Dec 2015 20:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22086 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 22086-submit@debbugs.gnu.org id=B22086.14507315351947 (code B ref 22086); Mon, 21 Dec 2015 20:59:02 +0000 Original-Received: (at 22086) by debbugs.gnu.org; 21 Dec 2015 20:58:55 +0000 Original-Received: from localhost ([127.0.0.1]:59141 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aB7Xj-0000VL-CI for submit@debbugs.gnu.org; Mon, 21 Dec 2015 15:58:55 -0500 Original-Received: from dancol.org ([96.126.100.184]:42928) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aB7Xh-0000VD-Cs for 22086@debbugs.gnu.org; Mon, 21 Dec 2015 15:58:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Message-ID:CC:To:Date:From:Subject:Content-Type:Content-Transfer-Encoding:MIME-Version:References:In-Reply-To; bh=lIg8c0Lr09mkgvGMui+mgHTzhiDwxby/8fwtJk3A2lo=; b=kfdppig6tbKWTQzDJlTfQRgz893Px0GxlozvdDk0Q9uskNG2dqAX2+6rymvsUjf9ESGYTr/jit1SZqihD3nwDmcBgjeZif5e/pfLIgWv5JYywEdrlgGRWTKyTDWvcV/NOHvAYb4nphQ04+3VIXUaque7PYy7e6pjaXeXXUsdzm8TeyxBUQpTwHXBumFqF0w+O/X+ws7OsAEf/2oS3evmKfgumnxfXGdEevFKzWz7dn4GpRyrK0Ql7X4KjHa24nzO1Km3flhNFFfE/G1B2QWoqlpERrY1A6jsUiviC08VPBjr9D+EVF2AN/4hTTE1s8d1HP35OTFEuevlIG3XQMX76A==; Original-Received: from mobile-166-176-184-25.mycingular.net ([166.176.184.25] helo=[10.106.207.182]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1aB7Xa-0001kq-NL; Mon, 21 Dec 2015 12:58:46 -0800 In-Reply-To: <20151221204913.GY238@brightrain.aerifal.cx> 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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:110257 Archived-At: On December 21, 2015 12:49:13 PM PST, Rich Felker wrote: >On Mon, Dec 21, 2015 at 12:08:46PM -0800, Daniel Colascione wrote: >> On 12/20/2015 08:06 PM, Rich Felker wrote: >> > On Sun, Dec 20, 2015 at 10:37:24PM -0500, Ken Brown wrote: >> >> On 12/20/2015 5:33 PM, Paul Eggert wrote: >> >>> While thinking over this patch I'd like to propose what should be >a >> >>> simpler approach. This new proposal is more radical, and so >should not >> >>> be applied to the emacs-25 branch, but it should make the port to >musl >> >>> etc. automatic. >> >>> >> >>> The simpler approach is to remove gmalloc.c, and to use the >system >> >>> memory allocator, i.e., to behave as if SYSTEM_MALLOC is defined >on all >> >>> platforms. >> >>> >> >>> We can still support hybrid malloc for Cygwin, if SYSTEM_MALLOC >wouldn't >> >>> work on Cygwin for some reason; and we can support the similar >hybrid on >> >>> Darwin, if it's still needed. >> >> >> >> SYSTEM_MALLOC doesn't work on Cygwin, largely because Cygwin's >> >> malloc doesn't support malloc_set_state and malloc_get_state. >There >> >> may be other problems too. (It's been a while since I tried it.) >> > >> > I don't see how this is possible; malloc_[gs]et_state do not exist >on >> > other systems either. Presumably this is some hack needed for the >> > dumper, which wouldn't be needed if malloc weren't used >pre-dumping. >> >> We really shouldn't be dumping the native heap at all, really. >> Eventually, Emacs should be a position-independent executable (as >should >> every other program), and to unexec a PIE, we need to emit >relocations, >> and to emit relocations, we need to know where all the pointers are. >We >> can't do that if the internal heap structure is opaque to us. > >Actually you can, because the internal heap structure is not what you >need to dump. The "lisp heap" is what you need to dump, and it's >walkable in the same way you walk it now for garbage collection >purposes. It should be possible to adapt the GC code into a dumper >that dumps only the lisp data (with relocations in a form emacs can >internally process, i.e. not relying on writing a new executable >binary with ELF-level or other system-specific relocs) and no unwanted >additional state; then, even static linking should work correctly. > >Rich Sure. That's the XEmacs portable dumper approach, and it works all right. I'm just worried that we might have implicit dependencies on the C heap being preserved across unexec. The same code we use to relocate when Emacs is a PIE would also help us do GC compaction. (We'd have to pin conservatively reachable roots.)