In article <2e4654a5-5435-bd41-2f47-75a3dcede...@gmx.com>, Kamil Rytarowski <n...@gmx.com> wrote: >-=-=-=-=-=- >-=-=-=-=-=- > >On 19.12.2017 14:59, Anders Magnusson wrote: >> Den 2017-12-19 kl. 14:45, skrev Christos Zoulas: >>> In article <c7e15629-8b30-0a40-ae62-fc893a29e...@ludd.ltu.se>, >>> Anders Magnusson <ra...@ludd.ltu.se> wrote: >>> >>>> IIRC it was not a problem to run Emacs, it was a problem to compile it. >>>> So if the user want to compile an old Emacs, COMPAT_80 or so must be >>>> added to the kernel. >>> And let's not forget all the old binaries that might be using it. >>> >> That was not a problem since they used the sbrk(3) version instead. >> ...which assumes that they are dynamically linked, of course :-) >> >> -- Ragge > >SYS_sstk, SYS_sbrk and SYS_vadvise are gone. > >sbrk(2) users: > - gpl2/libmalloc > - LLVM (Process::GetMallocUsage()) > - am-utils (debug) > - unbound (debug) > - binutils / nm (debug) > - binutils / gas (debug) > - binutils / ld (debug) > - binutils / libiberty (debug) > - gcc / libiberty (debug) > - gdb > - lib/libbsdmalloc > - lib/libc/gmon/gmon.c > - lib/libc/stdlib/jemalloc.c (USE_BRK) > - lib/libc/stdlib/malloc.c > - tests/lib/libc/gen/t_dir.c (hack for hand-made leak-detector) > - tests/lib/libc/sys/t_mlock.c (sbrk(0)) > >brk(2) users: > - lib/libc/stdlib/malloc.c
I think at this point we've made enough progress removing stuff; we should file this into a PR so that it does not get lost, but this for me new is a first world problem, and there are other more important things to spend time on... christos
