This is the mail archive of the gcc-bugs@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]

[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770

--- Comment #28 from Jan Hubicka <hubicka at ucw dot cz> 2010-12-11 21:01:08 UTC ---
So I take that, the ctor order is to support priotities, since the
.ctor.priority sections get merged into single and ordered in increasing rather
than decreasing order, while init_array gets around the problem.

> Shared libraries are OK. Only static ones may have this issue.
> 
> > think that means adding linker smarts that detect that there are both
> > .ctor.* and .init_array.* sections and issuing an error -- not a warning
> 
> I will work on a linker patch.

Can't linker be told to translate .ctor section into init_array upon seeing the
fact that both are used? (or just do it by default)

> 
> We need a gcc option to select .ctor or .init_array.

We can have that, but I can imiagine this to be hard to handle for users when
dealing with environment having multiple compiler - i.e. user can use icc or
PathScale (or old GCC) that uses .ctors and it will be refused to link with
system library because that one was built with new GCC...

Also with LTO we probably want to swap the construction and destruction order.
I immitated the ctor/dtor mechanizm.  Given that things can be freely reversed,
I would go for that.

Also it would be nice to decide if LTO is right WRT mixing LTO and non-LTO
objects
together.

Thanks for explanation!
Honza


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