This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: extend dl-minimal malloc implementation
On Thu, Aug 17, 2017 at 6:43 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 08/17/2017 09:34 AM, H.J. Lu wrote:
>> On Thu, Aug 17, 2017 at 6:10 AM, Zack Weinberg <zackw@panix.com> wrote:
>>> On Thu, Aug 17, 2017 at 2:41 AM, Andreas Schwab <schwab@suse.de> wrote:
>>>> On Aug 16 2017, Zack Weinberg <zackw@panix.com> wrote:
>>>>
>>>>> What I was trying to suggest, earlier, was that *before* either (a) or
>>>>> (b) we should go through the entire of ld.so and try to *remove* as
>>>>> many allocations as possible, at which point it might make sense not
>>>>> to have malloc in there at all - "just" send all remaining allocations
>>>>> directly to mmap (not sbrk; leave sbrk for the "real" malloc). That
>>>>> may take rearchitecting - but so may just converting alloca to malloc,
>>>>> as you point out. I admit I have no idea whether this is even
>>>>> feasible.
>>>>
>>>> You still need something on top of mmap, unless you want to waste a lot
>>>> of memory.
>>>
>>> _Do_ we, though? Why does ld.so need to make any allocations at all
>>> above and beyond mapping in the libraries? It's an open question as
>>> far as I'm concerned.
>>
>> Do we know how many calls to free within ld.so before the regular free
>> takes over?
>
> Yes, DJ had data on this because he tracked it with the new dl-minimal.c
> changes he was working on...
>
> DJ?
Should we open a bug report for memory leak in ld.so because of
this?
--
H.J.