[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