[PATCH v4 3/3] csu: Implement and use _dl_early_allocate during static startup

[Adhemerval Zanella]

On 06/05/2022 07:00, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> On 05/05/2022 15:03, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
>>>> I still think there will be way simpler to just use mmap here, it will allow
>>>> to use a generic version without the need to fiddle with a Linux specific 
>>>> (it will be required just a wrapper to MMAP_CALL_INTERNAL, instead of an
>>>> implementation that need to know both sbrk and mmap internals).
>>>
>>> We need to wrap the difference in error checking as well.
>>>
>>>> I think you even clean up all the dl-brk.c and similar files required to
>>>> make brk/sbrk work on the loader with an allocator that only uses mmap.
>>>
>>> At the cost of additional VMAs, sure.  We won't be able to reuse the
>>> unused tail of the allocation easily because we do not know the page
>>> size yet.  __minimal_malloc does not yet work at this point.  We also
>>> lose some ASLR.  I'm not convinced it's worth it.
>>
>> It is another code that does something similar to __minimal_malloc to
>> a specific usage, so now we have another allocation scheme that is used
>> solely for static initialization.  And it does something different than
>> __minimal_malloc, so has different semantic.
>>
>> I am not really against it, but initialization code is already 
>> quite complex with a lot of different paths for dynamic/static case,
>> so I think it would be good to have single loader/static allocation 
>> code.  
> 
> As I said, we don't have the page size yet at this point, and
> __minimal_malloc needs to know that.  And there are likely other
> obstacles to consolidation.

But for !SHARED we do call _dl_aux_init before ARCH_SETUP_TLS, so
we can access GRLO(dl_pagesize).  

> How can we move this forward?

I am still not very found of bleeding misc/sbrk.c details to Linux
dl-early_allocate.c, but this is not a blocker for the patch.