Request for priority initialization feedback (from C++ ABI group)

[Jim Dehnert]

An issue is under discussion in the C++ ABI group for which we would
like broader feedback.  A feature of several implementations that we
would like to standardize allows assigning priorities to initialization
calls (primarily, but not exclusively, global object constructors).
This leads to a requirement for sorting (with the priority as key) the
set of initialization operations (equivalent to the .init_array
entries).

You can find the issue discussion on our web page at:

	http://reality.sgi.com/dehnert_engr/cxx/cxx-open.html#C2

There are two outstanding proposals.  One is described as part of the
above at:

	http://reality.sgi.com/dehnert_engr/cxx/cxx-open.html#c2-proposal

(Ignore the part about generalized sorting for purposes of this
discussion.)  It defines a new section type, and allows implementations
ranging from essentially no static linker work (it must recognize the
distinct section, but may do nothing but combine them and leave the
sorting to the runtime) to linker sorting (which may be a simple
in-place sort after combining the sections).

The second proposal is to use the equivalent of a current gnu feature,
which treats a section name suffix of the form "$abc" as a sort key,
and requires the linker to sort the sections before combining them.

We are looking for opinions about the two approaches.  I would
characterize their respective advantages as follows (note that I wrote
the first one, and presumably have some bias :-) :

First approach:

 1) Some participants are concerned about their ability to _require_
    the linker to do the sorting, although there is concensus that it
    is better to do it at link time than at runtime.  (We are
    particularly interested in whether this is a major concern.)
    The first approach allows the linker to do virtually nothing
    besides normal section coalescing.

 2) The actual sort operation, if the linker does it (or the runtime
    for that matter), can be a simple in-place sort of the coalesced
    section.  It does not require the linker to sort input sections
    before coalescing them.

 3) There is no sensitivity to the section name (one of SGI's pet
    peeves).

Second approach:

 1) More generality -- the same sorting mechanism can be used for other
    applications once implemented.  (Of course, it can be implemented
    whether or not it is used for initialization priority.)

 2) Existing implementation (in gnu ld).

Note that both approaches need to be prepared to expand pointers to
64-bits if 32-bit objects are used for 64-bit programs.  This
observation hasn't been made in our discussions, but means that the
second approach cannot be implemented in completely general ignorance
of the kind of section involved.  (The proposal for the first approach
mentions this.)

Thoughts and relevant information?

Jim

-		Jim Dehnert  x3-4272