Hello, Svante Signell, on Sat 10 Dec 2016 20:52:20 +0100, wrote: > On Thu, 2016-12-08 at 16:32 +0100, Richard Braun wrote: > > On Thu, Dec 08, 2016 at 03:40:34PM +0100, Svante Signell wrote: > > > > > OK! Then maybe the sbrk() feature should be flagged as not > > > available in order > > > not to fool configure and the compiler. In fact FreeBSD/arm64 did > > > exactly that, > > > see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24892 So that > > > platform is on > > > the same par as GNU/Hurd then. On all other supported platforms > > > emacs builds and > > > runs perfectly, though. > > Samuel. It seems like sbrk() is still needed for elf/dl-sysdep.c, and > cannot be removed easily. Why, when malloc() is the preferred usage?
See the comment. The allocation there *has* to be exactly at that address. > Otherwise sbrk for Hurd should be removed completely, since it does not > work as expected. No need to remove it completely: you could just remove the sbrk/brk aliases: weak_alias (__brk, brk) and weak_alias (__sbrk, sbrk) dl-sysdep.c will still be able to use __sbrk. I'm however concerned with breaking all applications which make use of brk/sbrk that way. Couldn't emacs be made to know that it shouldn't use sbrk on GNU/Hurd? > I saw your patch wrt PIE builds, that feels like a brown paper bag > fix! Which patch? What is the relation with the problem at stake? > > Then find out how they do it, and see if we can do the same. > > Richard: Any ideas on where to start? I patched brk/sbrk to return > proper error codes, but to no avail. emacs' configure probably doesn't check for the actual value being returned. Just try to remove the aliases. But really I don't think we want to do that, but rather hardcode in emacs that sbrk shouldn't be used on GNU/Hurd. > And, BTW, linux and kfreebsd use > the implementations in misc, but not Hurd, why? See the code, it's just a wrapper around __brk. Samuel