[PATCH] Introduce ELF_INITFINI for all architectures
Florian Weimer
fweimer@redhat.com
Tue Aug 14 10:06:00 GMT 2018
On 08/08/2018 10:42 PM, Adhemerval Zanella wrote:
>> + bool have_init = ELF_INITFINI && l->l_info[DT_INIT] != NULL;
>> +
>> /* Are there any constructors? */
>> - if (l->l_info[DT_INIT] == NULL
>> - && __builtin_expect (l->l_info[DT_INIT_ARRAY] == NULL, 1))
>> + if (!have_init && __builtin_expect (l->l_info[DT_INIT_ARRAY] == NULL, 1))
>> return;
>
> Maybe __glibc_likely.
Both INIT and INIT_ARRAY are extremely common, perhaps due to the TM
registration code in GCC. I've dropped the early return in the attached
patch.
>> +/* This file contains definitions specifying behavior of a platform
>> + (CPU + kernel) combination. It must be usable from both assembler
>> + sources and C sources. Definitions should be namespace-clean. */
>> +
>
> Shouldn't we note ABI take in consideration as well?
Sorry, ABI in what sense?
>> +#ifndef _PLATFORM_PARAMS_H
>> +#define _PLATFORM_PARAMS_H
>> +
>> +/* Most platforms use _init/_fini symbols to call constructors and
>> + destructors. If defined to 0, the dynamic loader will ignore
>> + DT_INIT and DT_FINI tags, and static binaries will not call the
>> + _init or _fini functions. */
>> +#define ELF_INITFINI 1
>
> I assume for new ABIs init_array is the prefered and the expected way to
> initialize constructors. Should we add a comment that new ports are
> expected set it as 0?
I'm not sure if that's happening with new ports.
Thanks,
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: csu.patch
Type: text/x-patch
Size: 14707 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20180814/30cabf03/attachment.bin>
More information about the Libc-alpha
mailing list