[PATCH v9 3/5] Fix assert during static startup (BZ 33326)

[Adhemerval Zanella Netto]

On 08/06/26 09:14, Adhemerval Zanella Netto wrote:
> 
> 
> On 08/06/26 07:46, Florian Weimer wrote:
>> * Adhemerval Zanella:
>>
>> I think the general issue is not right: During startup, we should not
>> use mmap to allocate the backing store.  We can preserve the assert
>> message and file name by copying them to on-stack buffer.  As no user
>> code should be running at this point, we do not need to be prepared for
>> arbitrarily-long assert messages (but we still should have a length
>> check, of course).
>>
>> Can we redirect to a different assert implementation during early
>> startup?
> 
> I think I can reinstate the assert wrapper [1]. I kept the assert used 
> simplify the the implementation and use the same code path.  We can use
> a stack allocated buffer and cap the message string, for glibc own usage we
> would know when we need to increase it.
> 
> But it also raises the question whether we do copy the buffer in this case,
> this assert will be only used during process startup and it would be triggered
> in cases that can be considered glibc issues.
> 
> [1] https://sourceware.org/pipermail/libc-alpha/2026-March/176039.html
It turned out that for the rtld it is already done by elf/dl-minimal.c
__assert_fail/__assert_perror_fail which only calls _dl_fatal_printf instead
of __libc_assert_fail (which in turn calls __libc_message_impl).

Now changing this to *static-pie* means making static-pie act more like
rtld and less lime a static binary: we will need to add some logic on
the libc __libc_message_impl to handle static-pie and/or adding some
mechanism to override assert (similar how it is done for rtld). I don't
think either worth the trouble.