Unexpected behavior regarding linking sections

[Alan Modra]

On Wed, Dec 12, 2018 at 05:23:02PM +0100, Felix von Leitner wrote:
> > > > Have a look at your default ld scripts (link with -Wl,--verbose).
> > > > Very likely you have a linker configured with --enable-initfini-array
> > > > which will put .ctors and .dtors from all but the various flavours of
> > > > crtbegin/end.o into .init_array and .fini_array.
> > > I don'd understand what that means.
> > If you don't understand what I said above then it's not very likely I
> > can help you further.
> 
> Please print out this email and revisit it in a few years.
> First rule in conversation: Assume your opposite knows something you
> don't.

Ironic.

[snip lots of frustration]
> Is it clearer now?

Yes, it's clear that you "know" some things about linker operation
that aren't true.  One misconception in particular stands out, that
.ctors in input files are always mapped to .ctors in an output file.
That isn't true.  It is also not true of other named sections.  A
linker may take a section from an input file and place it in a
differently named output section.  This is not a rare occurrence.  For
example, you'll see it happen with input sections like ".text.hot" and
".rodata.cst4".  GNU ld generally performs mapping of input to output
sections under control of a linker script.

For the record, I understand what you are trying to do.  I not only
read your email but I linked your testcase myself, after fixed an
error or two (%d vs. %ld).  I also know exactly why GNU ld is behaving
as it is regarding .ctors/.dtors.  That behaviour is reasonable given
that it is desirable to move the entire toolchain from using
.ctors/.dtors to the ELF gABI standard of .init_array/.fini_array but
GNU ld must support mixing old and new object files in a way that
keeps proper constructor/destructor ordering.

-- 
Alan Modra
Australia Development Lab, IBM