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,gmane.os.freebsd.devel.hackers Subject: bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture Date: Fri, 18 Nov 2016 14:22:07 -0800 Organization: UCLA Computer Science Department Message-ID: <1dc6fa8c-7378-6e4e-1d9e-86c962fc48bb@cs.ucla.edu> References: <82a03552-8f33-2dbe-6bb5-54f649b29db7@cs.ucla.edu> <86vavxs2cn.fsf@members.fsf.org> <5adee8d9-8f08-9536-a95f-ae64719d6a0f@cs.ucla.edu> <40f8df50-b431-1ebd-221c-df2aa453aa81@cs.ucla.edu> <06ee71fd-1a64-d32b-862e-c725807aef4e@cs.ucla.edu> <876cf047-82fb-f08c-bbb3-024206f6fabd@cs.ucla.edu> <83twb6dnkm.fsf@gnu.org> <8637ipm0nb.fsf@lostca.se> <5ec481c4-41e1-c7dd-433d-f533653b132f@cs.ucla.edu> 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 1479507793 30769 195.159.176.226 (18 Nov 2016 22:23:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 18 Nov 2016 22:23:13 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 Cc: freebsd-hackers@freebsd.org, Brooks Davis , 24892@debbugs.gnu.org, Ashish SHUKLA To: Ed Maste Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 18 23:23:09 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 1c7rYr-0007OM-BL for geb-bug-gnu-emacs@m.gmane.org; Fri, 18 Nov 2016 23:23:09 +0100 Original-Received: from localhost ([::1]:39128 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7rYu-0006qz-N0 for geb-bug-gnu-emacs@m.gmane.org; Fri, 18 Nov 2016 17:23:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48334) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7rYp-0006qq-9W for bug-gnu-emacs@gnu.org; Fri, 18 Nov 2016 17:23:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c7rYk-0004bI-D7 for bug-gnu-emacs@gnu.org; Fri, 18 Nov 2016 17:23:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47112) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c7rYk-0004b8-90 for bug-gnu-emacs@gnu.org; Fri, 18 Nov 2016 17:23:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c7rYk-0007wH-0M; Fri, 18 Nov 2016 17:23:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 18 Nov 2016 22:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24892 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 24892-submit@debbugs.gnu.org id=B24892.147950773730449 (code B ref 24892); Fri, 18 Nov 2016 22:23:01 +0000 Original-Received: (at 24892) by debbugs.gnu.org; 18 Nov 2016 22:22:17 +0000 Original-Received: from localhost ([127.0.0.1]:34278 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c7rY1-0007v3-7i for submit@debbugs.gnu.org; Fri, 18 Nov 2016 17:22:17 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:33738) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c7rXz-0007uq-IL for 24892@debbugs.gnu.org; Fri, 18 Nov 2016 17:22:16 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id D3F5916006F; Fri, 18 Nov 2016 14:22:08 -0800 (PST) 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 4Uy_Ra3XdPtE; Fri, 18 Nov 2016 14:22:08 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 15A7F160070; Fri, 18 Nov 2016 14:22:08 -0800 (PST) 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 Rz5yrrQtfNxQ; Fri, 18 Nov 2016 14:22:08 -0800 (PST) Original-Received: from [192.168.1.9] (unknown [47.153.178.162]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id E296B16006F; Fri, 18 Nov 2016 14:22:07 -0800 (PST) In-Reply-To: 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:125851 gmane.os.freebsd.devel.hackers:58201 Archived-At: Ed Maste wrote: > arm64 support was first available in a release in FreeBSD 11.0, without= sbrk, and sbrk never existed on the stable/11 branch. Thanks, I didn't know that. So Emacs has never worked in this environment= . > it seems there's an implementation that allocates memory out of a large= array in .bss used for some platforms - could we make use of that here? Quite possibly. Unfortunately the code that uses that array (in gmalloc.c= ) also=20 uses sbrk to move the break past the end of the large array. The large ar= ray is=20 intended for use only during the build process; during ordinary execution= , sbrk=20 is used. Perhaps Emacs could work around the problem by supplying a user-space sbr= k=20 emulator, which uses mmap to support the old-fashioned model where the he= ap is=20 contiguous. Is that something that could be done easily? That is, is ther= e some=20 way to reserve the address space for a potentially-large Emacs heap right= after=20 .bss, such that library calls to malloc and mmap won't use this address s= pace?=20 That might do the trick. Brooks Davis wrote: > What does emacs actually need from sbrk()? Could it get by with someth= ing with the same interface allocating from .bss or does it need its allo= cations to be at the end of .bss? I think more the latter. The problem with a fixed-size .bss is that whate= ver=20 size we pick during the build is likely to be wrong for users. Also, Emac= s saves=20 the entire build-time .bss into an executable, so an enormous .bss will b= e=20 counterproductive.