bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture

[Brooks Davis <brooks@freebsd.org>]

[-- Attachment #1: Type: text/plain, Size: 1992 bytes --]

On Fri, Nov 18, 2016 at 08:21:04AM -0800, Paul Eggert wrote:
> 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 
> this serious Emacs bug report, which says that Emacs no longer works on FreeBSD 
> 11.x arm64:
> 
> https://bugs.gnu.org/24892
> 
> The referenced FreeBSD discussion appears to be under the misapprehension that 
> sbrk is useful only to estimate how much memory is in use, and since this use 
> has long been wrong sbrk should be unceremoniously removed. Unfortunately, this 
> assumption is incorrect for Emacs, as (bleeding-edge) Emacs uses its own 
> allocator during its build process, and reverts to malloc only during user 
> operation. (The build-time Emacs makes a copy of itself in a new executable, and 
> relies on sbrk during the build.) Obviously this is dicey and we are planning to 
> change Emacs to make it more portable; however, this will require nontrivial 
> reengineering on our part.
> 
> In the meantime we respectfully request that sbrk functionality be kept in 
> FreeBSD 11.x arm64 for a while. It is fine to mark it as deprecated or obsolete, 
> or even rename it, but please do not remove the functionality entirely.

Under FreeBSD's stability rules if we shipped ANY release for a platforms
(e.g. arm64, riscv) with a system call, we must support it for the life
of the architecture (approximately FOREVER).  As such, if any other
solution is viable, we'd prefer that.

What does emacs actually need from sbrk()?  Could it get by with
something with the same interface allocating from .bss or does it need
its allocations to be at the end of .bss?  I'm happy to put some time
into a userspace workaround if one is viable.

-- Brooks

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]