Re: SYS_sbrk removal proposal

[christos%astron.com@localhost (Christos Zoulas)]

In article <2e4654a5-5435-bd41-2f47-75a3dcedee72%gmx.com@localhost>,
Kamil Rytarowski  <n54%gmx.com@localhost> 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-fc893a29e49a%ludd.ltu.se@localhost>,
>>> Anders Magnusson  <ragge%ludd.ltu.se@localhost> 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