[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #107 from Ian Lance Taylor --- This problem report is closed. If you want to report a new bug, please open a new problem report. Using init_priority does work in general across translation units. There may be a bug in your environment. In your new problem report, be sure to give an example of source code, and mention the exact version of the compiler and linker you are using.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #106 from Marcelo Richter --- Update: init_priority not work across TUs. It works to change constructor order in same CPP file. Between .cpp files or between cpp and library, it not work.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 Marcelo Richter changed: What|Removed |Added CC||marcelo at brs dot ind.br --- Comment #105 from Marcelo Richter --- Any news on that? With gcc 4.8.4 (ARM target), init_priority attribute doesn't work with a static library and main C++ file. I have a class declared in library with "__attribute__ ((init_priority (101)))". In main project, another class declared with no attributes. The main class constructor is called BEFORE library constructor (with high priority attribute).
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #104 from Ian Lance Taylor 2012-04-22 22:26:50 UTC --- I'm not sure what you mean. Each object file will have a .init_array section. The linker will assemble those sections in the usual manner. The order of global constructors in a single translation unit is fixed by the language standard. The thing that is not fixed is the order between translation units. So each object file will have a .init_array section that will typically contain only a single pointer. The order in which those input .init_array sections are combined into an output .init_array section will determine the order in which the constructors are run.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #103 from Ivan Godard 2012-04-22 21:52:40 UTC --- I may be just displaying my ignorance, but my understanding is that order under init_array is governed by order of pointers within the array itself, and where the pointed-to sections are in the file is irrelevant. After all, a reason for the switch was so Firefox could get the inits with fewer disk reads. So even if I can rearrange the init_array. sections nothing will change, because the order is set by the pointers and you have left me with no control over that. Not so?
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #102 from Ian Lance Taylor 2012-04-22 21:16:14 UTC --- To be clear, nothing has changed in collect2. The only thing that has changed is that data that was being emitted in the .ctors section is now being emitted in the .init_array section (and similarly for .dtors and .fini_array). The reason this makes a difference is that the dynamic linker executes the entries in .init_array, whereas gcc-provided startup code executes the entries in .ctors. And they happen to execute the entries in different orders. The whole point of the change is in fact to execute the entries in a different order, though I continue to think that this would be better handled in a different way. In other words, it is not the case that gcc is producing an anoymous opaque object that the linker can not change.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #101 from Ivan Godard 2012-04-22 19:35:08 UTC --- Well, it's easy to say that it's the other guy's problem, but it isn't. You are assuming that the linker is always gnu ld; for big shops with multi-platform targets that's not necessarily true. We can't expect vendors of other linkers to deal with gcc decisions. Instead, may I suggest that the problem is in collect2, which is where gcc generates an init_array; the linker just includes the table in the load module, unchanged from what collect2 gives it. I there's another bug list separately for collect2 then please give me the URL and I'll go away and bother them instead. You used to produce a section for each init; the linker knows about sections, so we can use the linker to enforce order. You are no longer producing a section for each init, but are instead jamming them together into an anonymous opaque object that a linker cannot change (hacks in your own linker notwithstanding). So long as you are going to do the jamming yourself, we mere users need some scripting mechanism to control it. Yes, there are options to preserve the "legacy" behavior. Until you get tired of supporting two mechanisms, or bitrot creeps into the "legacy". I have enough trouble preserving C++ as a language of choice here in this shop, without gratuitous breakage of things that in truth are not part of the standard but nevertheless are needed for a working tool.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #100 from Paolo Carlini 2012-04-22 18:43:18 UTC --- As as side, Sunday-type, observation, we don't normally use the work 'ticket' here (if only because no money is involved, at least, not in the open ;)
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #99 from Jan Hubicka 2012-04-22 18:33:44 UTC --- > OK to re-open this ticket? If ctor order was/is controllable via linker script, it seems that you need similar feature for init arrays. In that case it is binutils feature, not GCC, and for that please fill in http://sourceware.org/bugzilla/ I am sorry for the trouble. As Iant pointed out, disabling initarray support may be viable solution for you in meantime. Honza
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #98 from Ivan Godard 2012-04-22 17:44:24 UTC --- It's OK if you reverse the default order - make it sideways if it gets a faster Firefox. We can cope. It's OK is you dump ctors for init_array if it simplifies your maintenance. We don't want you to be stuck with maintaining both systems. But give us some (documented!) way to control how the init_array gets populated, for when there's something you didn't think of in your planning. Like "using command line order breaks when there are intra-library order dependencies". Please. OK to re-open this ticket?
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #97 from Ian Lance Taylor 2012-04-22 17:03:24 UTC --- One option you have is to configure gcc with --disable-initfini-array.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 Ivan Godard changed: What|Removed |Added CC||igodard at pacbell dot net --- Comment #96 from Ivan Godard 2012-04-22 08:01:55 UTC --- I'm a user that the switch to init_array just broke. Details are in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068, but to summarize: Large production environment Must use other compilers too Third party binaries as well as our code. Each project represented as a .a library. Static initialization dependencies between TUs in a project (and hence within .o's in a library). Static initialization dependencies among projects. Executables link some explicit .o's with libraries from other projects, and must provide semantically correct ordering. Hence: Can't use priorities (not supported on other compilers; can't add pragmas to 3rd party code; maintaining a global absolute order over hundreds of files that change dependencies each release is a headache) Can't use init_array (no way to control ordering among files extracted from a single library) So for a decade we have manually maintained a dependency graph (relative, not absolute like priorities) and used that to put explicit commands to position .ctor sections into a linker script. That broke in 4.7. Yes, the language leaves inter-TU order unspecified. But we the users have to control that particular unspecified to get our job done. There used to be a way to exercise that control, through hooks in the linker script. You have now gratuitously taken away that control *and left nothing else to use instead*. At this point our choices appear to be to stay at 4.6 forever (or at least until the roar of complaint makes you do something), or to do our own collect2. Pretty poor.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #95 from Jan Hubicka 2012-04-19 15:07:27 UTC --- > It is misleading to think that the linker accumulates code in translation unit > order for a C++ program. E.g., that is not what happens for template code or > string constants. And of course the placement of functions called in > different > translation units is arbitrary. > > A lot of work was done in both GNU ld and gold to move constructors from > .ctors > to .init_array, all to improve startup latency for firefox. If that same > amount of work were done on better layout of initialization code, we would > improve all programs. I did some work on this, too. GCC now identify the functions executed only at startup and global destruction time and puts them into .text.startup subsections. This completely elliminate the problem for implicit constructors generated by #include . Those just calls libstdc++ constructor that checks flags and does nothing most of time. Sadly I think gold still ignore those, so the optimization works only with GNU LD. With more complex constructors this logic helps. It is however not resonable to assume that ctors execute and access only stuff that can be recognized by reachability analysis to be only used at startup (after all they are constructing something). It is resonable to assume that static constructor in translation unit X will access functions and variables of unit X (because it is constructing them) + of course some other common stuff needed to do its job that is shared across rest of construction process. For this it makes IMO a lot of sense to make the (implicit to user) order of execution of constructors match the (impicit) order how sections are laid out. Sure that there are counterexamples where this does not help, but it is good heuristics and what we do by default now is almost always the slowest variant. Firefox is really not a special case here. C++ makes it extremely easy to introduce static constructors and destructors and thus most large C++ programs expose this problems (at least I know that Chrome and OOo do). I am not quite sure how linker ordering plugins and code layout is going to help here better. Some linkers do automatic reordering based on reconstructed callgraph. I prototyped code layout pass (ipa-reorder) based on static analysis of the callgraph at LTO. It works by clustering the callgraph/varpool nodes into sequences based on the presence of references hoping to get related code together. In my tests it however reaches very mixed results on Mozilla, because static analysis quickly lose track of virtual calls and use of pointers. It still seems to me that switching the default ctor execution order, at risk of breaking non-conforming C++ programs, is a good idea here. We get measurable improvements for most of large C++ packages out there and hopefully the fallout is not going to be great - many other runtimes already execute ctors in forwarding order. We could get the static function/variable reordering pass into GCC, implement in linker reordering and do reordering based on profile feedback, but all those are rather ortogonal to the issue discussed here. Honza
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #94 from Ian Lance Taylor 2012-04-19 00:14:01 UTC --- It is misleading to think that the linker accumulates code in translation unit order for a C++ program. E.g., that is not what happens for template code or string constants. And of course the placement of functions called in different translation units is arbitrary. A lot of work was done in both GNU ld and gold to move constructors from .ctors to .init_array, all to improve startup latency for firefox. If that same amount of work were done on better layout of initialization code, we would improve all programs. Gold already supports arbitrarily sophisticated section layout via plugins, and I do not think it would be hard to add that support to GNU ld as well. I really think that this whole approach has been chasing the wrong thing, fixing a side effect rather than attempting to address the real problem. In any case, on the issue at hand, changing the default order is the conservative approach. Firefox can use an option.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #93 from Taras Glek 2012-04-18 04:48:18 UTC --- (In reply to comment #92) > As I said in comment #47 and elsewhere, you should not confuse the order in > which entries appear in .ctors or .init_array sections with the order in which > they appear in the binary. If you want better layout in the binary, then tell > the linker to change the layout in the binary. The order in the .ctors or > .init_array sections is irrelevant. The fact that reversing the order of > constructors happens to give you faster startup for firefox is just a > coincidence. Don't let that coincidence drive you toward choices that make no > sense. I am not confusing the order in which entries appear. My concerns is the order in which code gets paged in from disk. Right now that's driven entirely by translation unit "concatenation" and how that relates to the order of ctor invocation. Currently the right thing(tm) happens, achieving the same by other means is considerably more complicated. There are 2 problems with using section ordering to solve this a) there is no way to do this kind of section ordering transparently(especially not by default) with current infrastructure. b) it doesn't work without lto because initializers pull in other code... I'll expand on b: We(C++ code like Firefox/Chrome/etc) have one initializer per TU. The initializer is often not self-contained and calls other code within the unit(and rarely in other units...this you can't solve without LTO) So if you pass a list of init sections to the linker...that list needs to be transitive and include all of the sections called from inits in order to achieve a useful level of locality post-reorder. Or you can keep TUs without any reordering, have decent locality(because related init code is generally nearby) and a sane page-in pattern if the order of init executions matches TU layout.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #92 from Ian Lance Taylor 2012-04-18 03:50:51 UTC --- As I said in comment #47 and elsewhere, you should not confuse the order in which entries appear in .ctors or .init_array sections with the order in which they appear in the binary. If you want better layout in the binary, then tell the linker to change the layout in the binary. The order in the .ctors or .init_array sections is irrelevant. The fact that reversing the order of constructors happens to give you faster startup for firefox is just a coincidence. Don't let that coincidence drive you toward choices that make no sense.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #91 from Taras Glek 2012-04-18 01:27:58 UTC --- (In reply to comment #90) > > Or that you kept the link command fixed, but switching to init_array gave > you significant speed up, which you don't want to lose? This.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #90 from Paul Pluzhnikov 2012-04-18 00:50:06 UTC --- (In reply to comment #89) > Your solution will reverse order of reference of .init_array entries with > regards to the linker commandline. > > Linking translation units A B C, will result in C B A execution order. Pardon my confusion ... AFAIU, before init_array was implemented, the .ctors *were* executed in C B A order (by the loader). Are you saying that you've re-ordered the link command line after init_array became available? Or that you kept the link command fixed, but switching to init_array gave you significant speed up, which you don't want to lose?
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #89 from Taras Glek 2012-04-17 23:58:00 UTC --- (In reply to comment #87) > > Just as a quick reminder, the reversed ctor execution order is big > > performance > > problem for C++ Apps inlcuding Mozilla and Chrome ;) > > So whatever we do, I would preffer to not have it by default. > > If the issue is the iteration over the contents of the final > .init_array section, this solution won't have that problem -- the > loader will still execute .init_array entries in forward order (we'll > be reversing them at link time). Your solution will reverse order of reference of .init_array entries with regards to the linker commandline. Linking translation units A B C, will result in C B A execution order. Unless you also change the linker to combine the translation units backwards(vs sequentially as is normal), this will ruin startup speed of chrome/firefox and every other large c++ program. > > If the issue is the code layout of the ctors themselves, that sounds > like something that could be fixed through code layout optimizations > (e.g., gold's --section-ordering-file option). Every single app would have to add this flag for good perf so some legacy build system can avoid reordering the .init_array section using a non-default flag.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #88 from H.J. Lu 2012-04-17 22:15:04
UTC ---
(In reply to comment #86)
> > I have seen codes like:
> >
> > void (*const init_array []) (void)
> > __attribute__ ((section (".init_array"), aligned (sizeof (void * =
> > {
> > &init_0,
> > &init_1,
> > &init_2
> > };
> >
> > I don't want to reverse its order.
>
> We will not reverse that order. Those three entries will all be in the
> same input section.
I assume init priority will be handled as usual.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #87 from ccoutant at google dot com 2012-04-17 21:52:12 UTC --- > Just as a quick reminder, the reversed ctor execution order is big performance > problem for C++ Apps inlcuding Mozilla and Chrome ;) > So whatever we do, I would preffer to not have it by default. If the issue is the iteration over the contents of the final .init_array section, this solution won't have that problem -- the loader will still execute .init_array entries in forward order (we'll be reversing them at link time). If the issue is the code layout of the ctors themselves, that sounds like something that could be fixed through code layout optimizations (e.g., gold's --section-ordering-file option). -cary
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #85 from Jan Hubicka 2012-04-17 21:06:55 UTC --- Just as a quick reminder, the reversed ctor execution order is big performance problem for C++ Apps inlcuding Mozilla and Chrome ;) So whatever we do, I would preffer to not have it by default.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #86 from ccoutant at google dot com 2012-04-17 21:09:15 UTC ---
> I have seen codes like:
>
> void (*const init_array []) (void)
> __attribute__ ((section (".init_array"), aligned (sizeof (void * =
> {
> &init_0,
> &init_1,
> &init_2
> };
>
> I don't want to reverse its order.
We will not reverse that order. Those three entries will all be in the
same input section.
-cary
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #84 from H.J. Lu 2012-04-17 20:28:25
UTC ---
(In reply to comment #83)
>
> Paul suggested to me offline that maybe you're asking about
> translation units with several .ctors or .init_array sections. Since
> that doesn't happen in practice, I don't really care so much, and
> would prefer to do the easy thing of just reversing the order of all
> input sections, even to the point of reversing the order of the
> sections within a translation unit. I think the important point is
> that we do not reverse the order of entries within a single input
> section.
>
I have seen codes like:
void (*const init_array []) (void)
__attribute__ ((section (".init_array"), aligned (sizeof (void * =
{
&init_0,
&init_1,
&init_2
};
I don't want to reverse its order.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #83 from ccoutant at google dot com 2012-04-17 20:10:07 UTC --- >> Didn't I just do that? > > Let me ask it again: > > The proposed --reverse-init-array switch will only reverse the order across > translation units, while keeping the same order within translation unit. > Is this correct? Maybe I'm misunderstanding the question. As I said before: If you have translation unit A with .ctors entries A1 and A2, and translation unit B with .ctors entries B1 and B2, we'll build a .init_array section with: B1 B2 A1 A2 Expanding on that, we will reverse the order of the individual input sections relative to one another, but we will not modify the contents of any input section at all. Everything I said for .ctors sections goes for .init_array sections, since we just map .ctors -> .init_array on the way in, and treat them as if they were .init_array sections from the beginning. Paul suggested to me offline that maybe you're asking about translation units with several .ctors or .init_array sections. Since that doesn't happen in practice, I don't really care so much, and would prefer to do the easy thing of just reversing the order of all input sections, even to the point of reversing the order of the sections within a translation unit. I think the important point is that we do not reverse the order of entries within a single input section. -cary
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #82 from H.J. Lu 2012-04-17 19:02:22 UTC --- (In reply to comment #81) > Didn't I just do that? > Let me ask it again: The proposed --reverse-init-array switch will only reverse the order across translation units, while keeping the same order within translation unit. Is this correct?
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #81 from ccoutant at google dot com 2012-04-17 18:52:11 UTC --- >> As Paul noted, this is a moot point in practice for .ctors, since GCC emits >> only a single .ctors entry per TU, but it could be significant for assembly >> code or for TUs with .init_array sections. > > That is my concern. .init_array section in the same TU can may have > more than one entry due to: > > 1. Assembly code. > 2. constructor attribute in C source. > 3. .init_array section attribute in C source. > > We need to spell out exactly what --reverse-init-array should do. Didn't I just do that? -cary
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #80 from H.J. Lu 2012-04-17 18:12:41 UTC --- (In reply to comment #79) > > As Paul noted, this is a moot point in practice for .ctors, since GCC emits > only a single .ctors entry per TU, but it could be significant for assembly > code or for TUs with .init_array sections. > That is my concern. .init_array section in the same TU can may have more than one entry due to: 1. Assembly code. 2. constructor attribute in C source. 3. .init_array section attribute in C source. We need to spell out exactly what --reverse-init-array should do.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #79 from Cary Coutant 2012-04-17 18:00:41 UTC --- (In reply to comment #77) > I believe .init_array keeps the same order of .ctors within > the same translation unit. The proposed --reverse-init-array > switch will only reverse the order across translation units, > while keeping the same order within translation unit. Is this > correct? Yes. If you have translation unit A with .ctors entries A1 and A2, and translation unit B with .ctors entries B1 and B2, we'll build a .init_array section with: B1 B2 A1 A2 As Paul noted, this is a moot point in practice for .ctors, since GCC emits only a single .ctors entry per TU, but it could be significant for assembly code or for TUs with .init_array sections. -cary
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #78 from Paul Pluzhnikov 2012-04-17 17:16:10 UTC --- (In reply to comment #77) > I believe .init_array keeps the same order of .ctors within > the same translation unit. I may be missing something, but I only see a single .ctors entry per CU, so I think your question is moot.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #77 from H.J. Lu 2012-04-17 15:41:04 UTC --- I believe .init_array keeps the same order of .ctors within the same translation unit. The proposed --reverse-init-array switch will only reverse the order across translation units, while keeping the same order within translation unit. Is this correct?
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #76 from Paul Pluzhnikov 2012-04-17
15:18:56 UTC ---
(In reply to comment #75)
> Can you provide a testcase?
// foo.h
struct Foo {
Foo(Foo *other) : x(other->x) { }
Foo() : x(42) { }
int x;
private:
Foo(const Foo&);
};
extern Foo foo_global;
// foo.cc
#include "foo.h"
Foo foo_global;
// main.cc
#include
#include "foo.h"
Foo foo(&foo_global);
int main() { assert(foo.x == 42); }
Above, foo.cc simulates a library, and main depends on that library having been
initialized.
Using pre-init_array GCC, this works:
g++ main.cc foo.cc && a.out
and this doesn't:
g++ foo.cc main.cc && ./a.out
a.out: main.cc:6: int main(): Assertion `foo.x == 42' failed.
Using post-init_array GCC, the behavior is reversed: natural link order
(libraries after main) is broken.
> ARM EABI has been using .init_array from day
> one. How does it work for ARM EABI?
It doesn't. We have a *lot* of programs that don't run on ARM though, and they
are all broken by this change.
Note: we do understand that the example above depends on undefined behavior,
and we do intend to eventually fix our source. But it will take a lot of
effort.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #75 from H.J. Lu 2012-04-17 14:47:27 UTC --- (In reply to comment #74) > We still have an unresolved issue here: we're effectively reversing the order > in which the ctors are run across translation units. While explicitly > undefined > by any standard, it was mentioned upthread that this would probably break a > lot > of code that depended on ctors for later translation units (e.g., a > statically-linked C++ library) running before those for earlier translation > units. And, in fact, we have been finding lots of such code. We've temporarily > worked around it by configuring GCC to continue to use .ctors sections, and by > turning off --ctors-in-init-array in the linker, but I'd think it would be > nice > to fix this. Can you provide a testcase? ARM EABI has been using .init_array from day one. How does it work for ARM EABI? > I'd like to propose a --reverse-init-array option to the linker that would > reverse the contributions to the .init_array section relative to one another > (but not the actual contents of each contribution). With this option, the > .init_array entries for translation unit A would come after those for > translation unit B, when A comes before B on the link command. This would > still > conform to the standards, but would provide a more reasonable ordering, since > it is natural to expect initializers for dependent libraries to execute before > those for code that depends on them (as is the case for shared libraries > already). > > As I recall the discussions from years ago when we first added .init_array, I > think we would have always preferred to have the dynamic loader execute the > .init_array entries in reverse, but we were trying to preserve the behavior > that had always been observed with the old .init section (which, obviously, > could not execute in reverse). I believe that was the original reason (or at > least part of it) that GCC put ctors in a separate section rather than using > .init or .init_array. Now that we're moving .ctors into .init_array, I think > it's more important to preserve the old behavior of ctors rather than the old > behavior of .init fragments. > > HJ, if I add this option to gold, would you add it to ld? > > If this is OK with everyone, we can then discuss whether or not the option > should be on by default. > I think we should preserve the old behavior as much as we can, by default. --reverse-init-array should be the default. Thanks.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 Cary Coutant changed: What|Removed |Added CC||ppluzhnikov at google dot ||com --- Comment #74 from Cary Coutant 2012-04-17 01:21:47 UTC --- We still have an unresolved issue here: we're effectively reversing the order in which the ctors are run across translation units. While explicitly undefined by any standard, it was mentioned upthread that this would probably break a lot of code that depended on ctors for later translation units (e.g., a statically-linked C++ library) running before those for earlier translation units. And, in fact, we have been finding lots of such code. We've temporarily worked around it by configuring GCC to continue to use .ctors sections, and by turning off --ctors-in-init-array in the linker, but I'd think it would be nice to fix this. I'd like to propose a --reverse-init-array option to the linker that would reverse the contributions to the .init_array section relative to one another (but not the actual contents of each contribution). With this option, the .init_array entries for translation unit A would come after those for translation unit B, when A comes before B on the link command. This would still conform to the standards, but would provide a more reasonable ordering, since it is natural to expect initializers for dependent libraries to execute before those for code that depends on them (as is the case for shared libraries already). As I recall the discussions from years ago when we first added .init_array, I think we would have always preferred to have the dynamic loader execute the .init_array entries in reverse, but we were trying to preserve the behavior that had always been observed with the old .init section (which, obviously, could not execute in reverse). I believe that was the original reason (or at least part of it) that GCC put ctors in a separate section rather than using .init or .init_array. Now that we're moving .ctors into .init_array, I think it's more important to preserve the old behavior of ctors rather than the old behavior of .init fragments. HJ, if I add this option to gold, would you add it to ld? If this is OK with everyone, we can then discuss whether or not the option should be on by default. -cary
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #73 from Jing Yu 2012-02-22 22:04:44 UTC --- Author: jingyu Date: Wed Feb 22 22:04:39 2012 New Revision: 184493 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184493 Log: 2012-02-21 Jing Yu Google Ref 47894 Backport from mainline r177933, r175181, r177963, r178116, r183299. 2011-08-20 H.J. Lu PR other/46770 * config.gcc (tm_file): Add initfini-array.h if .init_arrary/.fini_array are supported. * crtstuff.c: Don't generate .ctors nor .dtors sections if USE_INITFINI_ARRAY is defined. * output.h (default_elf_init_array_asm_out_constructor): New. (default_elf_fini_array_asm_out_destructor): Likewise. * varasm.c (elf_init_array_section): Likewise. (elf_fini_array_section): Likewise. (get_elf_initfini_array_priority_section): Likewise. (default_elf_init_array_asm_out_constructor): Likewise. (default_elf_fini_array_asm_out_destructor): Likewise. * config/initfini-array.h: New. 2011-06-18 H.J. Lu PR other/49325 * acinclude.m4 (gcc_AC_INITFINI_ARRAY): Properly check if .init_array can be used with .ctors on targets. * configure: Regenerated. 2011-08-22 H.J. Lu * acinclude.m4 (gcc_AC_INITFINI_ARRAY): Error if __ELF__ isn't defined. * configure: Regenerated. 2011-08-26 Rainer Orth PR target/50166 * acinclude.m4 (gcc_AC_INITFINI_ARRAY): Check count in main. * configure: Regenerate. 2012-01-19 Jakub Jelinek PR bootstrap/50237 * config/initfini-array.h: Guard content of the header with #ifdef HAVE_INITFINI_ARRAY. * configure.ac: Move gcc_AC_INITFINI_ARRAY much later into the file. Add initfini-array.h to tm_file here. * acinclude.m4 (gcc_AC_INITFINI_ARRAY): For non-ia64 do a linker test. * config.gcc: Don't add initfini-array.h to tm_file here. * configure: Regenerated. Added: branches/google/gcc-4_6/gcc/config/initfini-array.h Modified: branches/google/gcc-4_6/gcc/ChangeLog.google-4_6 branches/google/gcc-4_6/gcc/acinclude.m4 branches/google/gcc-4_6/gcc/configure branches/google/gcc-4_6/gcc/configure.ac branches/google/gcc-4_6/gcc/crtstuff.c branches/google/gcc-4_6/gcc/output.h branches/google/gcc-4_6/gcc/varasm.c
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #72 from Jing Yu 2012-02-18 06:03:30 UTC --- Author: jingyu Date: Sat Feb 18 06:03:26 2012 New Revision: 184369 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184369 Log: 2012-02-17 Jing Yu Google Ref 47894 2011-12-07 H.J. Lu Backport from mainline r177933. 2011-08-20 H.J. Lu PR other/46770 * config.gcc (tm_file): Add initfini-array.h if .init_arrary/.fini_array are supported. * crtstuff.c: Don't generate .ctors nor .dtors sections if USE_INITFINI_ARRAY is defined. * output.h (default_elf_init_array_asm_out_constructor): New. (default_elf_fini_array_asm_out_destructor): Likewise. * varasm.c (elf_init_array_section): Likewise. (elf_fini_array_section): Likewise. (get_elf_initfini_array_priority_section): Likewise. (default_elf_init_array_asm_out_constructor): Likewise. (default_elf_fini_array_asm_out_destructor): Likewise. * config/initfini-array.h: New. Added: branches/google/gcc-4_6/gcc/initfini-array.h Modified: branches/google/gcc-4_6/gcc/ChangeLog.google-4_6 branches/google/gcc-4_6/gcc/config.gcc branches/google/gcc-4_6/gcc/crtstuff.c branches/google/gcc-4_6/gcc/output.h branches/google/gcc-4_6/gcc/varasm.c
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #71 from Jing Yu 2012-02-18 04:55:37 UTC --- Author: jingyu Date: Sat Feb 18 04:55:31 2012 New Revision: 184368 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184368 Log: 2012-02-17 Jing Yu Google Ref 47894 2011-12-07 H.J. Lu Backport from mainline r177933. 2011-08-20 H.J. Lu PR other/46770 * config.gcc (tm_file): Add initfini-array.h if .init_arrary/.fini_array are supported. * crtstuff.c: Don't generate .ctors nor .dtors sections if USE_INITFINI_ARRAY is defined. * output.h (default_elf_init_array_asm_out_constructor): New. (default_elf_fini_array_asm_out_destructor): Likewise. * varasm.c (elf_init_array_section): Likewise. (elf_fini_array_section): Likewise. (get_elf_initfini_array_priority_section): Likewise. (default_elf_init_array_asm_out_constructor): Likewise. (default_elf_fini_array_asm_out_destructor): Likewise. * config/initfini-array.h: New. Added: branches/google/gcc-4_6_2-mobile/gcc/initfini-array.h Modified: branches/google/gcc-4_6_2-mobile/gcc/ChangeLog.google-4_6 branches/google/gcc-4_6_2-mobile/gcc/config.gcc branches/google/gcc-4_6_2-mobile/gcc/crtstuff.c branches/google/gcc-4_6_2-mobile/gcc/output.h branches/google/gcc-4_6_2-mobile/gcc/varasm.c
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 H.J. Lu changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|target |other Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #70 from H.J. Lu 2011-08-20 20:06:16 UTC --- Fixed for GCC 4.7.0.
