https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63223
--- Comment #9 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> --- (In reply to Georg-Johann Lay from comment #8) > (In reply to Jorn Wolfgang Rennecke from comment #4) > > (In reply to Georg-Johann Lay from comment #1) > > do_global_dtors is supposed to start at the start and increment from there. > > I see it used to be half-way wrong and half-way correct. > > (Starting at the start, decrementing for __AVR_HAVE_ELPM__, incrementing > > otherwise.) > > However, you now made it all the way use an incorrect order - starting at > > the > > end and incrementing from there. > > Is there a rationale for this? > > The old code was broken as it decremented begainning at the start address. > The flaw never came apparent for __dtors_start = __dtors_end or with > simulators that terminated in exit. > > The new code uses the same traverse direction like __do_global_ctors. > > Is the order of .ctors, .dtors defined in any way? I.e. how do you express > that constructor A must run before constructor B in the C program? Same for > destructors. The C++ standard says that destructors have to run in reverse order of completion of constructors. crtstuff.c:__do_global_ctors_aux starts at the first constructor, and increments from there; crtstuff.c:__do_global_dtors_aux starts at the last destructor, and decrements from there.
