From owner-freebsd-hackers@freebsd.org Fri Nov 18 16:28:28 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63482C47621 for ; Fri, 18 Nov 2016 16:28:28 +0000 (UTC) (envelope-from eggert@cs.ucla.edu) Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 445EB1648 for ; Fri, 18 Nov 2016 16:28:27 +0000 (UTC) (envelope-from eggert@cs.ucla.edu) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id AAD2B16013D; Fri, 18 Nov 2016 08:21:06 -0800 (PST) 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 M3xDkwrfKVPI; Fri, 18 Nov 2016 08:21:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9577F160148; Fri, 18 Nov 2016 08:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 eQpfxs-v1rro; Fri, 18 Nov 2016 08:21:04 -0800 (PST) Received: from [192.168.1.9] (unknown [47.153.178.162]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 7730916013D; Fri, 18 Nov 2016 08:21:04 -0800 (PST) Subject: Re: bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture To: Ashish SHUKLA 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> Cc: 24892@debbugs.gnu.org, freebsd-hackers@freebsd.org From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <5ec481c4-41e1-c7dd-433d-f533653b132f@cs.ucla.edu> Date: Fri, 18 Nov 2016 08:21:04 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <8637ipm0nb.fsf@lostca.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 18 Nov 2016 16:41:40 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 16:28:28 -0000 Ashish SHUKLA wrote: > One of the FreeBSD developer has > pointed me to this ongoing discussion[1] on freebsd-hackers@ list. > > References: > [1] https://lists.freebsd.org/pipermail/freebsd-hackers/2016-November/= 050144.html OK, thanks, I'll CC: freebsd-hackers. FreeBSD hackers: this is following = up on=20 this serious Emacs bug report, which says that Emacs no longer works on F= reeBSD=20 11.x arm64: https://bugs.gnu.org/24892 The referenced FreeBSD discussion appears to be under the misapprehension= that=20 sbrk is useful only to estimate how much memory is in use, and since this= use=20 has long been wrong sbrk should be unceremoniously removed. Unfortunately= , this=20 assumption is incorrect for Emacs, as (bleeding-edge) Emacs uses its own=20 allocator during its build process, and reverts to malloc only during use= r=20 operation. (The build-time Emacs makes a copy of itself in a new executab= le, and=20 relies on sbrk during the build.) Obviously this is dicey and we are plan= ning to=20 change Emacs to make it more portable; however, this will require nontriv= ial=20 reengineering on our part. In the meantime we respectfully request that sbrk functionality be kept i= n=20 FreeBSD 11.x arm64 for a while. It is fine to mark it as deprecated or ob= solete,=20 or even rename it, but please do not remove the functionality entirely.