From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Wolfgang Jenkner Newsgroups: gmane.emacs.bugs Subject: bug#22086: 25.1.50; [PATCH] Integrate the musl hybrid mallo Date: Wed, 10 Feb 2016 13:27:37 +0100 Message-ID: <854mdgpwdx.fsf@iznogoud.viz> References: <85poynxvgy.fsf@iznogoud.viz> <56BA76DC.8030001@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1455108411 21433 80.91.229.3 (10 Feb 2016 12:46:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 10 Feb 2016 12:46:51 +0000 (UTC) Cc: 22086@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Feb 10 13:46:40 2016 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 1aTUAA-0007BF-CK for geb-bug-gnu-emacs@m.gmane.org; Wed, 10 Feb 2016 13:46:30 +0100 Original-Received: from localhost ([::1]:38698 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTUA4-0005Yu-1n for geb-bug-gnu-emacs@m.gmane.org; Wed, 10 Feb 2016 07:46:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60221) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTU9l-0005Cc-Dn for bug-gnu-emacs@gnu.org; Wed, 10 Feb 2016 07:46:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aTU9i-0003uJ-7W for bug-gnu-emacs@gnu.org; Wed, 10 Feb 2016 07:46:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53379) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTU9i-0003uF-3x for bug-gnu-emacs@gnu.org; Wed, 10 Feb 2016 07:46:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aTU9h-00052Y-P8 for bug-gnu-emacs@gnu.org; Wed, 10 Feb 2016 07:46:01 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: <85poynxvgy.fsf@iznogoud.viz> Resent-From: Wolfgang Jenkner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Feb 2016 12:46: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.145510831019317 (code B ref 22086); Wed, 10 Feb 2016 12:46:01 +0000 Original-Received: (at 22086) by debbugs.gnu.org; 10 Feb 2016 12:45:10 +0000 Original-Received: from localhost ([127.0.0.1]:34287 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aTU8s-00051U-BH for submit@debbugs.gnu.org; Wed, 10 Feb 2016 07:45:10 -0500 Original-Received: from b2bfep15.mx.upcmail.net ([62.179.121.60]:51659) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aTU8q-00051F-Bo for 22086@debbugs.gnu.org; Wed, 10 Feb 2016 07:45:09 -0500 Original-Received: from edge12.upcmail.net ([192.168.13.82]) by b2bfep15.mx.upcmail.net (InterMail vM.8.01.05.18 201-2260-151-151-20140610) with ESMTP id <20160210124459.TZWR27614.b2bfep15-int.chello.at@edge12.upcmail.net> for <22086@debbugs.gnu.org>; Wed, 10 Feb 2016 13:44:59 +0100 Original-Received: from iznogoud.viz ([91.119.83.35]) by edge12.upcmail.net with edge id Gckz1s0040ljrGj0CckzcZ; Wed, 10 Feb 2016 13:44:59 +0100 X-SourceIP: 91.119.83.35 Original-Received: from wolfgang by iznogoud.viz with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aTU8g-0000Pd-Me; Wed, 10 Feb 2016 13:44:58 +0100 User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1.50 (berkeley-unix) 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:112851 Archived-At: On Tue, Feb 09 2016, Paul Eggert wrote: >> I think, (g)calloc and hybrid_calloc are still needed, though? > > I suppose you're right, so I installed your patch in master. Thanks, I could have pushed it myself, I just posted it here to avoid interfering with your plans concerning this stuff. > this stuff is all pretty iffy. Why does Emacs redefine calloc but not > aligned_alloc or posix_memalign, for example? Here on FreeBSD 10, in the non-hybrid case both aligned_alloc and posix_memalign are redefined; in the hybrid case there is only hybrid_aligned_alloc: /opt/src/emacs-calloc-non-hybrid;!2;: nm -g src/emacs | grep align 00000000005e4210 R QCalign_to 0000000000b83df8 D _aligned_blocks 0000000000b83df0 D _aligned_blocks_mutex 00000000005c92b0 T aligned_alloc 00000000005c8e70 T galigned_alloc 00000000005c90e0 T memalign 00000000005c90f0 T posix_memalign /opt/src/emacs-calloc-non-hybrid;!3;: cd ../emacs-calloc-hybrid/ /opt/src/emacs-calloc-hybrid;!4;: nm -g src/emacs | grep align 00000000005e3380 R QCalign_to U aligned_alloc@@FBSD_1.3 00000000005c71a0 T hybrid_aligned_alloc /opt/src/emacs-calloc-hybrid;!5;: > Is it because we know no library uses these newer allocators? Just for the record, as you know this stuff way better than I do: IIUC, we need hybrid_ versions for all allocation functions that are actually used in code statically linked with emacs (at least those which somewhere refer to memory allocated before dumping, but I don't think there's much point in making a distinction here). On the other hand, in the non-hybrid case, we have to override all of them (if they exist in libc), so that references in shared libraries linked with emacs to, say, posix_memalign don't resolve to the libc version. > Anyway, I suppose it's better to play it safe and continue to redefine > calloc, the way Emacs has done for decades, until we have a better way > to do dumping and restoring and memory allocation for such. In the hybrid case we just do #define calloc hybrid_calloc etc. in the emacs sources, so that's not a problem. On the other hand, in the non-hybrid case, what has been done for decades (i.e. overriding the libc implementation of calloc etc.) has turned out to be a problem after all (bug#22085).