__attribute __（（constructor））はどのように正確に機能しますか？

セットアップが必要なことは明らかです。

1. 正確にはいつ実行されますか？
2. 括弧が2つあるのはなぜですか？
3. ある__attribute__機能は？マクロ？構文？
4. これはCで動作しますか？C ++？
5. 機能する関数は静的である必要がありますか？
6. いつ__attribute__((destructor))実行しますか？

Objective-Cの例：

__attribute__((constructor))
static void initialize_navigationBarImages() {
  navigationBarImages = [[NSMutableDictionary alloc] init];
}

__attribute__((destructor))
static void destroy_navigationBarImages() {
  [navigationBarImages release];
}

1. 共有ライブラリが読み込まれると、通常はプログラムの起動時に実行されます。
2. これがすべてのGCC属性です。おそらくそれらを関数呼び出しと区別するためです。
3. GCC固有の構文。
4. はい、これはCおよびC ++で機能します。
5. いいえ、関数は静的である必要はありません。
6. デストラクタは、共有ライブラリがアンロードされたときに、通常はプログラムの終了時に実行されます。

したがって、コンストラクタとデストラクタが機能する方法は、共有オブジェクトファイルに、それぞれコンストラクタとデストラクタ属性でマークされた関数への参照を含む特別なセクション（ELFでは.ctorsと.dtors）が含まれていることです。ライブラリがロード/アンロードされると、ダイナミックローダープログラム（ld.soまたはsomesuch）は、そのようなセクションが存在するかどうかを確認し、存在する場合は、そのセクションで参照されている関数を呼び出します。

考えてみてください。ユーザーが静的リンクと動的リンクのどちらを選択したかに関係なく、起動/シャットダウン時に同じコードが実行されるように、通常の静的リンカーにも同様の魔法があると思われます。

.init/ .finiは非推奨ではありません。それはまだELF標準の一部であり、それは永遠に続くと思います。.init/ 内の.finiコードは、コードがロード/アンロードされるときにloader / runtime-linkerによって実行されます。つまり、ELFロード（共有ライブラリなど）ごとにコード.initが実行されます。そのメカニズムを使用して、とほぼ同じことを実現することはまだ可能 __attribute__((constructor))/((destructor))です。それは古い学校ですが、いくつかの利点があります。

.ctors/ .dtorsメカニズムは、たとえばsystem-rtl / loader / linker-scriptによるサポートを必要とします。これは、コードがベアメタルで実行される深く埋め込まれたシステムなど、すべてのシステムで利用できるとはほど遠いものです。つまり__attribute__((constructor))/((destructor))、GCCでサポートされている場合でも、それを構成するのはリンカー次第であり、それを実行するのはローダー（場合によってはブートコード）なので、実行されるかどうかは不明です。代わりに.init/ を使用するため.finiの最も簡単な方法は、リンカーフラグを使用することです-Wl -init my_init -fini my_fini。

両方の方法をサポートするシステムでは、1つの可能な利点は、の.init前.ctorsにコードが実行され、.fini後にコードが実行されることです.dtors。順序が関連している場合、それは少なくとも1つの粗雑ですが、init関数とexit関数を区別する簡単な方法です。

主な欠点は、ロード可能なモジュールごとに_init1つ以上の_fini関数を簡単に持つことができず、おそらく.soモチベーションを上げるよりもコードをフラグメント化する必要があることです。もう1つは、上記のリンカーメソッドを使用すると、元の_initおよび_finiデフォルト関数（によって提供されるcrti.o）が置き換えられることです。これは通常、あらゆる種類の初期化が行われる場所です（Linuxでは、これがグローバル変数割り当てが初期化される場所です）。その回避策はここで説明されています

上記のリンクでは、元の_init()場所へのカスケードはまだ残っているため必要ないことに注意してください。callアセンブリがインラインでは、x86-ニーモニック及びアセンブリ（例えば、ARMなど）、他の多くのアーキテクチャで完全に異なって見えることになるから関数を呼び出しています。つまり、コードは透過的ではありません。

.init/ .finiと.ctors/の.detorsメカニズムは似ていますが、完全ではありません。.init/のコードは.fini「そのまま」実行されます。つまり、.init/ .finiにいくつかの関数を含めることが.soできますが、多くの小さなファイルのコードを分割せずに純粋なCで完全に透過的にそれらを配置することは、AFAIKの構文上困難です。

.ctors/ .dtors異なっより組織化されています.init/ .fini。.ctors/ .dtorsセクションは両方とも、関数へのポインタを持つ単なるテーブルであり、「呼び出し元」は、各関数を間接的に呼び出すシステム提供のループです。つまり、ループ呼び出し元はアーキテクチャ固有にすることができますが、システムの一部であるため（つまり、存在する場合）、それは重要ではありません。

次のスニペットは.ctors、主に同じ方法で新しい配列を関数配列に追加__attribute__((constructor))します（メソッドはと共存でき__attribute__((constructor)))ます。

#define SECTION( S ) __attribute__ ((section ( S )))
void test(void) {
   printf("Hello\n");
}
void (*funcptr)(void) SECTION(".ctors") =test;
void (*funcptr2)(void) SECTION(".ctors") =test;
void (*funcptr3)(void) SECTION(".dtors") =test;

関数ポインタを完全に異なる自己開発セクションに追加することもできます。このような場合、変更されたリンカースクリプトと、ローダー.ctors/ .dtorsループを模倣した追加の関数が必要です。しかし、これを使用すると、実行順序をより適切に制御し、引数内でリターンコードを処理するイータを追加できます（たとえば、C ++プロジェクトでは、グローバルコンストラクターの前または後に何かを実行する必要がある場合に役立ちます）。

__attribute__((constructor))/((destructor))可能な場合は私が好みますが、それはごまかしのように感じても、シンプルでエレガントなソリューションです。私のようなベアメタルプログラマーにとって、これは必ずしも選択肢ではありません。

『リンカーとローダー』という本の良い参考文献。

このページでは、constructorおよびdestructor属性の実装と、ELF内で機能するためのELF内のセクションについて詳しく説明しています。ここで提供された情報を要約した後、私は追加の情報を少しまとめて（上記のMichael Ambrusからのセクションの例を借用して）概念を説明し、私の学習に役立つ例を作成しました。これらの結果は、サンプルのソースとともに以下に提供されています。

このスレッドで説明したように、constructorおよびdestructor属性は、オブジェクトファイルの.ctorsおよび.dtorsセクションにエントリを作成します。関数への参照は、3つの方法のいずれかでいずれかのセクションに配置できます。（1）section属性を使用する。（2）constructorおよびdestructor属性、または（3）インラインアセンブリ呼び出し（Ambrusの回答のリンクを参照）。

使用constructorとdestructor属性を使用すると、さらに前に、その実行順序を制御するために、コンストラクタ/デストラクタに優先順位を割り当てることができmain()呼び出されるか、それが戻った後。指定された優先度の値が低いほど、実行優先度が高くなります（main（）の前に高い優先度の前に実行され、main（）の後に高い優先度の後に実行されます）。指定する優先度の値は、コンパイラーが実装のために0〜100の優先度の値を予約するため、より大きくなければなりません100。優先度付きのconstructorまたdestructorはは、優先度なしのconstructorまたはの前に実行destructorされます。

'section'属性を使用するか、インラインアセンブリを使用すると、関数参照.initを.finiELFコードセクションに配置して、コンストラクターの前とデストラクタの後にそれぞれ実行することもできます。.initセクションに配置された関数参照によって呼び出された関数は、（通常のように）関数参照自体の前に実行されます。

以下の例でそれらのそれぞれを説明しようとしました：

#include <stdio.h>
#include <stdlib.h>

/*  test function utilizing attribute 'section' ".ctors"/".dtors"
    to create constuctors/destructors without assigned priority.
    (provided by Michael Ambrus in earlier answer)
*/

#define SECTION( S ) __attribute__ ((section ( S )))

void test (void) {
printf("\n\ttest() utilizing -- (.section .ctors/.dtors) w/o priority\n");
}

void (*funcptr1)(void) SECTION(".ctors") =test;
void (*funcptr2)(void) SECTION(".ctors") =test;
void (*funcptr3)(void) SECTION(".dtors") =test;

/*  functions constructX, destructX use attributes 'constructor' and
    'destructor' to create prioritized entries in the .ctors, .dtors
    ELF sections, respectively.

    NOTE: priorities 0-100 are reserved
*/
void construct1 () __attribute__ ((constructor (101)));
void construct2 () __attribute__ ((constructor (102)));
void destruct1 () __attribute__ ((destructor (101)));
void destruct2 () __attribute__ ((destructor (102)));

/*  init_some_function() - called by elf_init()
*/
int init_some_function () {
    printf ("\n  init_some_function() called by elf_init()\n");
    return 1;
}

/*  elf_init uses inline-assembly to place itself in the ELF .init section.
*/
int elf_init (void)
{
    __asm__ (".section .init \n call elf_init \n .section .text\n");

    if(!init_some_function ())
    {
        exit (1);
    }

    printf ("\n    elf_init() -- (.section .init)\n");

    return 1;
}

/*
    function definitions for constructX and destructX
*/
void construct1 () {
    printf ("\n      construct1() constructor -- (.section .ctors) priority 101\n");
}

void construct2 () {
    printf ("\n      construct2() constructor -- (.section .ctors) priority 102\n");
}

void destruct1 () {
    printf ("\n      destruct1() destructor -- (.section .dtors) priority 101\n\n");
}

void destruct2 () {
    printf ("\n      destruct2() destructor -- (.section .dtors) priority 102\n");
}

/* main makes no function call to any of the functions declared above
*/
int
main (int argc, char *argv[]) {

    printf ("\n\t  [ main body of program ]\n");

    return 0;
}

出力：

init_some_function() called by elf_init()

    elf_init() -- (.section .init)

    construct1() constructor -- (.section .ctors) priority 101

    construct2() constructor -- (.section .ctors) priority 102

        test() utilizing -- (.section .ctors/.dtors) w/o priority

        test() utilizing -- (.section .ctors/.dtors) w/o priority

        [ main body of program ]

        test() utilizing -- (.section .ctors/.dtors) w/o priority

    destruct2() destructor -- (.section .dtors) priority 102

    destruct1() destructor -- (.section .dtors) priority 101

この例は、コンストラクタ/デストラクタの動作を固めるのに役立ちました。うまくいけば、他の人にも役立つでしょう。

以下は、これらの便利でありながら見苦しい構造をどのように、なぜ、そしていつ使用するかについての「具体的な」（そしておそらくは有用な）例です...

Xcodeはどの決定する「グローバル」「ユーザーデフォルト」を使用してXCTestObserver、クラスそれの心を吐き出すに包囲されたコンソール。

この例では...この疑似ライブラリを暗黙的にロードするときにlibdemure.a、テストターゲットアラのフラグを使用して呼び出します...

OTHER_LDFLAGS = -ldemure

したい..

1. ロード時（つまり、 XCTest、テストバンドルをロードする）、「デフォルト」XCTest「オブザーバー」クラスをオーバーライドします...（constructor関数を介して）PS：私が知る限り..ここで行われたことはすべて、私の内部で同等の効果で実行できますクラスの+ (void) load { ... }メソッド。

2. この場合、テストを実行します。この場合、ログの非常に冗長性が低くなります（要求に応じて実装）

3. 「グローバル」XCTestObserverクラスを元の状態に戻します。XCTestバンドワゴンで取得されていない他の実行を妨害しないように（別名。libdemure.a）。これは歴史的にdealloc.. で行われたと思いますが、私はその古いばかをいじり始めるつもりはありません。

そう...

#define USER_DEFS NSUserDefaults.standardUserDefaults

@interface      DemureTestObserver : XCTestObserver @end
@implementation DemureTestObserver

__attribute__((constructor)) static void hijack_observer() {

/*! here I totally hijack the default logging, but you CAN
    use multiple observers, just CSV them, 
    i.e. "@"DemureTestObserverm,XCTestLog"
*/
  [USER_DEFS setObject:@"DemureTestObserver" 
                forKey:@"XCTestObserverClass"];
  [USER_DEFS synchronize];
}

__attribute__((destructor)) static void reset_observer()  {

  // Clean up, and it's as if we had never been here.
  [USER_DEFS setObject:@"XCTestLog" 
                forKey:@"XCTestObserverClass"];
  [USER_DEFS synchronize];
}

...
@end

リンカーフラグがない場合...（報復を要求するファッションポリスがクパチーノに集結しますが、必要に応じて、ここでは Appleのデフォルトが優先されます。）

リンカフラグを使用して-ldemure.a...（わかりやすい結果、gasp ... "ありがとうconstructor/ destructor" ... 群衆は乾杯）

これは別の具体的な例です。共有ライブラリ用です。共有ライブラリの主な機能は、スマートカードリーダーと通信することです。ただし、実行時にudpを介して「構成情報」を受け取ることもできます。udpは、初期化時に開始する必要があるスレッドによって処理されます。

__attribute__((constructor))  static void startUdpReceiveThread (void) {
    pthread_create( &tid_udpthread, NULL, __feigh_udp_receive_loop, NULL );
    return;

  }

ライブラリはcで書かれました。