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
Are there users of old !jemalloc allocators? If not, I propose to delete
them as obsolete.
sbrk(2) is mostly used for debugging purposes, to find out the end of
heap ("sbrk(0)").
libc/gmon should be switched away from sbrk(2).
There is a need for improved debugging facilities to introspect the
jemalloc(3) internals, something comparable to mallinfo from <malloc.h>
in GNU. I require it for the LLVM Scudo allocator tests. It could be
reused in the place of "sbrk(0)" in the existing debug code. It's not an
urgent priority right now for me so I need to move on to more
prioritized tasks for me.
Attachment:
signature.asc
Description: OpenPGP digital signature