Re: extend dl-minimal malloc implementation

[Carlos O'Donell <carlos at redhat dot com>]

On 08/11/2017 10:18 AM, Adhemerval Zanella wrote:
> 
> 
> 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.

Moving to an entirely new API is a possibility.

But would we use that API for *every* allocation in the loader?

If we did then that would be a clean break where we could provide an early
malloc that aborts to find any cases of malloc that leak into the early
bootstrap.

-- 
Cheers,
Carlos.