On 19.12.2017 23:22, Christos Zoulas wrote: > 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 > I agree that this is not the most important one to rework brk(2)/sbrk(2) software. I've filed: lib/52842: Obsolete brk(2)/sbrk(2)
Attachment:
signature.asc
Description: OpenPGP digital signature