This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: extend dl-minimal malloc implementation

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 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 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]