Issue 82: Initializer priorities

[Jim Dehnert]

Since I promised to summarize the minimum ABI support required for this:

	Define a new section type, SHT_CXX_PRIORITY_INIT.

	The linker must concatenate the SHT_CXX_PRIORITY_INIT sections
	in the linked output file.  (Note that this is the defined
	default behavior for an unrecognized section type.)

On a system where the linker does no more than this, the C++
implementation must do the following:

	In bracketing files for the link (e.g. crt1.o and crtn.o),
	emit delimiting labels in the SHT_CXX_PRIORITY_INIT section,
	and entries in INITARRAY that call an initialization
	routine that passes the labels (all STV_HIDDEN to avoid
	conflicts between DSOs).  The call at the beginning would
	sort the SHT_CXX_PRIORITY_INIT vector by priority and invoke
	the negative-priority initializers, and the one at the end
	would invoke the positive-priority initializers.

So, I think the ABI-required support for this version is almost
nothing, and even the C++ library support is trivial.  (This is part of
the reason I think this is a good idea even though SGI hasn't
previously supported this feature.)  I also think that a vendor serious
about the extension would probably want to do the sorting in the
linker, but since it can be done in place after constructing the output
section, that's not hard, either (a simple call to STL sort :-).
It could be made more powerful by also doing insertion of
initialization entries specied in other ways, but that has a smaller
benefit probably.

The alternate proposal, based on the current g++ implementation,
handles the sorting by encoding the sort key in the section name,
and sorting sections.  That is, one might have sections .cxi$5,
.cxi$3, .cxi$9 in various object files, and the linker would produce a
single concatenated section ordered .cxi$3, .cxi$5, .cxi$9.

The advantages of this proposal are that it is more general (it can
sort sections for other purposes, and the sorted units need not be
the same size), and gnu already implements it.

Its disadvantages are that (a) it is a harder sorting problem,
since the sections must be sorted in the linker prior to section
layout, (b) the linker _must_ support the sorting, (c) it might need
more sections, since different priorities must be handled by putting
the entries in different sections, and (d) it depends on
interpretation of the section name instead of section types and
attributes.

Jim

-		Jim Dehnert  x3-4272