Date: Fri, 18 Nov 2016 14:22:07 -0800
From: Paul Eggert <eggert@cs.ucla.edu>
To: Ed Maste <emaste@freebsd.org>
Cc: Ashish SHUKLA <ashish.is@lostca.se>, freebsd-hackers@freebsd.org, 24892@debbugs.gnu.org, Brooks Davis <brooks@freebsd.org>
Subject: Re: bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture
Message-ID: <1dc6fa8c-7378-6e4e-1d9e-86c962fc48bb@cs.ucla.edu>
In-Reply-To: <CAPyFy2AL_OZWYpp%2BtiLSro_3WK1-H8Pdjy4-ZhUQChMQqageUw@mail.gmail.com>
References: <82a03552-8f33-2dbe-6bb5-54f649b29db7@cs.ucla.edu> <86vavxs2cn.fsf@members.fsf.org> <5adee8d9-8f08-9536-a95f-ae64719d6a0f@cs.ucla.edu> <mvminrxc7f2.fsf@hawking.suse.de> <c9396165-da2e-3c41-ec2b-070ce9c885bb@cs.ucla.edu> <mvmtwbfachr.fsf@hawking.suse.de> <40f8df50-b431-1ebd-221c-df2aa453aa81@cs.ucla.edu> <mvmfumz8e2u.fsf@hawking.suse.de> <06ee71fd-1a64-d32b-862e-c725807aef4e@cs.ucla.edu> <mvm60nv8cky.fsf@hawking.suse.de> <876cf047-82fb-f08c-bbb3-024206f6fabd@cs.ucla.edu> <83twb6dnkm.fsf@gnu.org> <8637ipm0nb.fsf@lostca.se> <5ec481c4-41e1-c7dd-433d-f533653b132f@cs.ucla.edu> <CAPyFy2AL_OZWYpp%2BtiLSro_3WK1-H8Pdjy4-ZhUQChMQqageUw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1dc6fa8c-7378-6e4e-1d9e-86c962fc48bb>