init_priority (was Re: Any further documentation available ?)

[Phil Edwards <pedwards at disaster dot jaj dot com>]

On Tue, Dec 12, 2000 at 07:15:06PM +0100, SchirmerH@Innovative-Systems.de wrote:
> 
> the online manual mentions
> 
> ---------
> -finit-priority 
> Support `__attribute__ ((init_priority (n)))' for controlling the
> order of initialization of file-scope objects. On ELF targets,
> this requires GNU ld 2.10 or later. 
> ---------
> 
> There is no further information about init_priority on the gcc.gnu.org :(

This has bothered me too.  I finally got a few spare minutes to look over
the code and write a testcase.  I'll probably add something to the manual.

In the process of playing with a testcase, I found something which should
probably be considered a bug.


> Can init_priority be used with COFF?

I don't know about COFF systems (I don't have one to test), but you can
try this and see.


> How does it work ?
> What's n ?

'n' is a number representing the priority of that object.  File-scope
objects are initialized in order from the lowest number (highest priority)
to the highest (lowest priority).  The particular values don't matter,
only their ordering.

Normally, file-scope objects in a single translation unit are initialized
in declaration order, usually.  But there is no guarantee about objects
from multiple units (files).

Here's a piece of example code.  (Compile all these example with recent
g++ and -finit-priority.)  This only does objects within a single file,
but it's enough to demonstrate.

    #include <iostream>

    struct P
    {
        P (int i) { std::cout << "Doing " << i << std::endl; }
    };

    static P first(900);
    static P second(300);
    static P third(3);

    int main ()
    {
        std::cout << "Blah." << std::endl;
        return 0;
    }

This prints

    Doing 900
    Doing 300
    Doing 3
    Blah.

because that is their definition order.  Now change those three definitions
to use the attribute, and just for clarity use the same integers as the
init-priority:

    static P first(900) __attribute__ ((init_priority (900)));
    static P second(300) __attribute__ ((init_priority (300)));
    static P third(3) __attribute__ ((init_priority (3)));

This will create the objects in the opposite order:

    Doing 3
    Doing 300
    Doing 900
    Blah.

It will also emit a warning, "requested init_priority is reserved for
internal use," on the object 'third'.  Currently the first hundred levels
are reserved, so 101 through (again, currently) 65535 are free for you.
If you had other file-scope objects with a default priority, like

    static P first(900) __attribute__ ((init_priority (900)));
    static P second(300) __attribute__ ((init_priority (300)));
    static P extra(8888);
    static P third(3) __attribute__ ((init_priority (3)));

then it would still come last; the default priority is the lowest.


BUG:  When the manual says that "this requires GNU ld 2.10 or later,"
they aren't joking.  When using the native Sun ld on the above code,
no warnings were printed, and the objects /never/ were initialized.
The executable printed "Blah." and exited.  Ouch!

We should warn in this case.  I'll see if I can do up a patch.


Luck++;
Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.