GNU bug report logs - #24892
{s,}brk removed from FreeBSD 11.x and later, arm64 architecture

Previous Next

Package: emacs;

Reported by: ashish.is <at> lostca.se (Ashish SHUKLA)

Date: Mon, 7 Nov 2016 06:09:02 UTC

Severity: important

Tags: fixed, patch

Merged with 28308

Fixed in version 26.1

Done: Noam Postavsky <npostavs <at> users.sourceforge.net>

Bug is archived. No further changes may be made.

Full log

Message #68 received at 24892 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Andreas Schwab <schwab <at> suse.de>
Cc: 24892 <at> debbugs.gnu.org, Ashish SHUKLA <ashish.is <at> lostca.se>
Subject: Re: bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64
 architecture
Date: Thu, 10 Nov 2016 08:23:40 -0800

On 11/10/2016 01:52 AM, Andreas Schwab wrote:
>> I'm curious about what the difference actually is,
> 17851608 bytes.

Thanks, and now I'm curious about where that difference comes from. I 
assume that unexelf.c code like this:

  #ifdef HAVE_SBRK
    new_break = sbrk (0);
  #else
    new_break = (byte *) old_bss_addr + old_bss_size + 17851608;
  #endif

would not be a good idea, even if it happens to work on this particular 
ARM64 build, as the number 17851608 must be specific to the platform 
and/or the build. (The number is 0 on x86-64, for example.) But how can 
I compute the number?

Would it work if we copied the old sbrk.S from the ARM64 C library, 
assemble and linked that, and then just call sbrk? (I don't have easy 
access to this platform so I can't try tricks like this myself.)
This bug report was last modified 7 years and 201 days ago.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.