This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: extend dl-minimal malloc implementation
On 11/08/2017 10:06, Florian Weimer wrote:
> On 08/11/2017 03:02 PM, Carlos O'Donell wrote:
>> Then we could use the bootstrap arena with minimal support, and eventually
>> free from it, and with correct accounting get 100% of it freed back to the
>> OS and we could monitor this. We would never allocate from this arena, and
>> we need not put it on the arena list / free list so it won't be used for
>> future allocations.
>
> If we never allocate from there, how would we achieve the goal of giving
> back unneeded memory?
>
> I also think that in the long term, we should separate ld.so data
> structures from the rest of libc, and even try to map keep read-only
> most of the time (when dlopen is not running).
My understanding of this change it to 1. remove alloca usage in loader and
2. enable dynarrays and scratch buffers usage. Do we care for interposable
malloc on loader if we move to this direction of separate ld.so data?
Also, what about a specialized memory allocator for loader which a possible
different signature than malloc? I think it would be feasible to extend
both dynarray and scratch buffer to enable parametrize the malloc functions
calls.