From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rich Felker 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 15:49:13 -0500 Message-ID: <20151221204913.GY238@brightrain.aerifal.cx> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1450731021 19163 80.91.229.3 (21 Dec 2015 20:50:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Dec 2015 20:50:21 +0000 (UTC) Cc: Wolfgang Jenkner , 22086@debbugs.gnu.org, Paul Eggert To: Daniel Colascione Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 21 21:50: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 1aB7PH-0000vG-Sl for geb-bug-gnu-emacs@m.gmane.org; Mon, 21 Dec 2015 21:50:12 +0100 Original-Received: from localhost ([::1]:47228 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aB7PH-0001H9-9U for geb-bug-gnu-emacs@m.gmane.org; Mon, 21 Dec 2015 15:50:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52514) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aB7PD-0001F3-9H for bug-gnu-emacs@gnu.org; Mon, 21 Dec 2015 15:50:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aB7P8-0003QD-97 for bug-gnu-emacs@gnu.org; Mon, 21 Dec 2015 15:50:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51535) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aB7P8-0003Q9-5V for bug-gnu-emacs@gnu.org; Mon, 21 Dec 2015 15:50:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aB7P7-0000J5-Ny for bug-gnu-emacs@gnu.org; Mon, 21 Dec 2015 15:50:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Rich Felker Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Dec 2015 20:50:01 +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.14507309781146 (code B ref 22086); Mon, 21 Dec 2015 20:50:01 +0000 Original-Received: (at 22086) by debbugs.gnu.org; 21 Dec 2015 20:49:38 +0000 Original-Received: from localhost ([127.0.0.1]:59137 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aB7Ok-0000IQ-F5 for submit@debbugs.gnu.org; Mon, 21 Dec 2015 15:49:38 -0500 Original-Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:42185 helo=brightrain.aerifal.cx) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aB7Oh-0000IE-Rk for 22086@debbugs.gnu.org; Mon, 21 Dec 2015 15:49:36 -0500 Original-Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1aB7OL-0007cD-00; Mon, 21 Dec 2015 20:49:13 +0000 Content-Disposition: inline In-Reply-To: <56785C4E.1060202@dancol.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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:110256 Archived-At: 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