This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: extend dl-minimal malloc implementation
- From: DJ Delorie <dj at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: fweimer at redhat dot com, libc-alpha at sourceware dot org
- Date: Fri, 11 Aug 2017 13:54:57 -0400
- Subject: Re: extend dl-minimal malloc implementation
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=dj at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com AB1C119CBCE
IMHO using malloc/free in ld.so should be considered as a way to avoid
using the stack for allocations; but this means that we have to be
careful to free everything we malloc, so that at the time we hand off
malloc to libc.so's malloc, the size of the "free list" is as small as
possible, which makes some of this discussion, well, "more moot" ;-)
At least, that was my design intent - the ld.so free list would normally
be small enough to not worry about, and anything left malloc'd at
handover would remain malloc'd for the life of the process.
If we intend to make ld.so's heap compatible with libc.so's heap, I
think the only long term solution, for maintenance reasons, is to use
malloc/malloc.c et all to implement both, perhaps via some #include/cpp
magic that gives us a stripped-down-but-compatible[*] version of the
full malloc just for ld.so.
[*] for example, without tcache/fastbins/consolidate but handing off a
heap that can be consolidated later, but remains compatible with future
hardening changes.