Movatterモバイル変換
[0]ホーム
This is the mail archive of thelibc-alpha@sourceware.orgmailing list for theglibc project.
Re: extend dl-minimal malloc implementation
On 08/17/2017 09:47 AM, H.J. Lu wrote:> 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? No. It's by design.This discussion is about changing the design to have a mostly realmalloc to use during bootstrap.Zack's point is to remove as much malloc as you can and see if westill need such a bootstrap malloc, eventually perhaps forbiddingmalloc in the early bootstrap.-- Cheers,Carlos.
[8]ページ先頭