[PATCH v6 4/5] Fix assert during static startup

Florian Weimer fweimer@redhat.com
Fri Feb 27 17:13:13 GMT 2026


* Adhemerval Zanella Netto:

>>> diff --git a/elf/tst-assert-startup-static.c b/elf/tst-assert-startup-static.c
>>> new file mode 100644
>>> index 0000000000..5b0dbdea32
>>> --- /dev/null
>>> +++ b/elf/tst-assert-startup-static.c
>>> @@ -0,0 +1,35 @@
>> 
>>> +/* The __tunables_init is called just before self-relocation and TLS setup,
>>> +   and the __libc_assert_fail is used internally for assert() calls.  */
>>> +extern _Noreturn __typeof (__assert_fail) __libc_assert_fail;
>>> +
>>> +void __tunables_init (char **env)
>>> +{
>>> +  __libc_assert_fail ("error", __FILE__, __LINE__, __func__);
>>> +}
>> 
>> The command should say that this is done to provoke an intentional
>> assert ion failure.
>> 
>> It's also not clear why you just write:
>> 
>>   assert (0);  /* This should print the usual message and not just crash.  */
>
> Because what I am trying to mimic here is how assert (0) works in the loader
> during process startup, and thus calling assert() will issue 
> __libc_assert (_(...)) which in turn may calls __dcgettext. 
>
> That's why I disable stack protection on __libc_assert_fail.c and not
> on assert.c

Fair enough, please add a comment. 8-)

>>> diff --git a/sysdeps/unix/sysv/linux/i386/raise_direct.c b/sysdeps/unix/sysv/linux/i386/raise_direct.c
>>> new file mode 100644
>>> index 0000000000..d27966fc9c
>>> --- /dev/null
>>> +++ b/sysdeps/unix/sysv/linux/i386/raise_direct.c
>>> @@ -0,0 +1,26 @@
>>> +/* Send a signal to a specific pthread.  Stub version.
>> 
>> Comment is not correct.
>> 
>> Overall direction seems okay.  I do wonder if we should just disable the
>> kernel syscall optimization for i386 static builds.  However, the
>> performance hit on current Intel CPUs is quite severe: getpid becomes
>> three times slower.  But then it's i386, so maybe for static builds
>> that's okay?
>
> I do not think we should go as drastic as this; the static build requirement
> is only to disable the vDSO optimization before TLS setup.  This specific
> case is really an outlier, where we trigger an assert before it.

I just dislike the maintenance overhead from this, especially now that
ia64 is gone.

Thanks,
Florian



More information about the Libc-alpha mailing list