Re: PATCH: Use .init_arrat/.fini_array if available

["H. J. Lu" <hjl at lucon dot org>]

On Sun, Mar 20, 2005 at 10:00:33AM -0800, Mark Mitchell wrote:
> Daniel Jacobowitz wrote:
> 
> >If the ARM port put entries in .ctors and ran them from the beginning
> >of .init_array, that would fix the problem.  I'm trying to figure out
> >whether there is a need to do that.  Currently constructors go in
> >.init_array directly.  I don't see any benefit except for these
> >artificial test cases.
> 
> I can't see any benefit to using .ctors.  That's just an extra level of 
> indirection.
> 
> I think that the fix probably lies in the form of a modification to the 
> GLIBC test case to accept the order of initialization given by the ARM 
> toolchain, absent something in the ELF spec that requires an ordering. 
> Also, we should consider the case that part of the program is built with 
> GCC, and part with some other compiler, and some arbitrary non-GNU 
> linker is used to build the final application.
> 

The .ctors section is an implementation detail. It can be called via
either .init or .init_array sections. There are no conflicts between
.ctors and .init_array. Different files can have mixed implementations
of .ctors + .init_array and .init_array only. There should be no
problems.

We should have source code compatibility for the order of

static void init (void) __attribute__ ((constructor));
void (*const init_array []) (void) __attribute__ ((section (".init_array")))

between different Linux platforms and different compilers. If we change
the order between

static void init (void) __attribute__ ((constructor));
void (*const init_array []) (void) __attribute__ ((section (".init_array")))

for different Linux platforms and different versions of gcc, it will
make the implementation much cleaner. In that case, I would suggest to
deprecate

static void init (void) __attribute__ ((constructor));

for the targets using .init_array and use

void (*const init_array []) (void) __attribute__ ((section (".init_array")))

exclusively to ensure source code compatibility.


H.J.