This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Sun, Mar 20, 2005 at 03:25:01PM -0500, Daniel Jacobowitz wrote:
> On Sun, Mar 20, 2005 at 11:02:52AM -0800, H. J. Lu wrote:
> > 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.
> 
> Did you read Mark's last paragraph?
> 
> > > 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.
> 
> This is required to work.  So on a target whose ABI defines
> .init_array, and does not mention .ctors, we should not be using .ctors
> at all.

You can call it .foo instead of .ctors. If you want to keep the same
order between

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

you can use .foo and .init_array to implement ctors in such a way that

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

will run before

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

I don't believe it will affect the ABI conformance.

> 
> > 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.
> 
> I am not convinced of this.  If you want things to happen in a certain
> order, you already have to take additional steps; for instance,
> multiple entries in either constructor or .init_array may happen in any
> order and most targets don't have any way to request more specific
> ordering (without using explicit source or link ordering for the
> .init_array entries).

I am not against the idea. If we put ctors in .init_array for one
Linux target, we should do it for all Linux targets which support
.init_array. At least, all Linux targets with glibc newer than Sept.
2002 will behave the same. Maybe we should start it with gcc 3.4,
which is the minimum version needed to build the current glibc, so that
the glibc order will be same on all targets.


H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]