4

共有ライブラリの再配置を調査していて、奇妙なことに遭遇しました。次のコードを検討してください。

int myglob;

int ml_util_func(int p)
{
    return p + 2;
}

int ml_func2(int a, int b)
{
    int c = ml_util_func(a);
    return c + b + myglob;
}

で非PIC共有ライブラリにコンパイルしgcc -sharedます。x86で実行されている32ビットのUbuntuでこれを行います。

結果には、 in.soへの呼び出しの再配置エントリがあります。onの出力は次のとおりです。ml_util_funcml_func2objdump -dR -Mintelml_func2

0000050d <ml_func2>:
 50d:   55                      push   ebp
 50e:   89 e5                   mov    ebp,esp
 510:   83 ec 14                sub    esp,0x14
 513:   8b 45 08                mov    eax,DWORD PTR [ebp+0x8]
 516:   89 04 24                mov    DWORD PTR [esp],eax
 519:   e8 fc ff ff ff          call   51a <ml_func2+0xd>
                        51a: R_386_PC32 ml_util_func
 51e:   89 45 fc                mov    DWORD PTR [ebp-0x4],eax
 521:   8b 45 0c                mov    eax,DWORD PTR [ebp+0xc]
 524:   8b 55 fc                mov    edx,DWORD PTR [ebp-0x4]
 527:   01 c2                   add    edx,eax
 529:   a1 00 00 00 00          mov    eax,ds:0x0
                        52a: R_386_32   myglob
 52e:   8d 04 02                lea    eax,[edx+eax*1]
 531:   c9                      leave  
 532:   c3                      ret    
 533:   90                      nop

命令のR_386_PC32再配置に注意してください。call

さて、私の質問は、なぜこの移転が必要なのですか? e8x86では「相対呼び出し...」でありml_util_func、同じオブジェクトで定義されているため、リンカーは動的ローダーに任せることなく、それと呼び出しの間の相対オフセットを計算できますか?

興味深いことに、ml_util_funcが宣言されている場合static、再配置はなくなり、リンカーはオフセットを正しく計算して挿入します。ml_util_funcリンカーがそれについて怠惰になるのは、エクスポートされていることについて何ですか?

PS: ロード時の再配置を理解するために、意図的に非 PIC コードで遊んでいます。

4

2 に答える 2

4

理由はわかりませんが、これは binutils からのコメントです:

binutils-2.11.90-20010705-src.tar.gz/bfd/elf32-i386.c: 679

      /* If we are creating a shared library, and this is a reloc
         against a global symbol, or a non PC relative reloc
         against a local symbol, then we need to copy the reloc
         into the shared library.  However, if we are linking with
         -Bsymbolic, we do not need to copy a reloc against a
         global symbol which is defined in an object we are

この再配置は、ユーザーがライブラリ内のグローバルシンボルをオーバーロードできるようにするために作成されたと思います。そして、-Bsymbolicこの機能を無効にし、ライブラリ自体からシンボルの再配置を生成しないようです。

http://www.rocketaware.com/man/man1/ld.1.htm

-Bsymbolic このオプションを使用すると、出力内のすべてのシンボリック参照がこのリンク編集セッションで解決されます。残りの実行時の再配置要件は、ベース相対再配置、つまりロード アドレスに関する変換だけです。シンボリック参照の解決に失敗すると、エラーが報告されます。

さまざまな -B モードと制限 (C++) の詳細な説明は次のとおりです。

http://developers.sun.com/sunstudio/documentation/ss12/mr/man1/CC.1.html

-Bバインディング

           Specifies whether a library binding for linking is
           symbolic, dynamic (shared), or static (nonshared).

           -Bdynamic is the default.  You can use the -B
           option several times on a command line.

           For more information on the -Bbinding option, see
           the ld(1) man page and the Solaris documentation.


           -Bdynamic directs the link editor to look for
           liblib.so files. Use this option if you want
           shared library bindings for linking.  If the
           liblib.so files are not found, it looks for
           liblib.a files.

           -Bstatic directs the link editor to look only for
           liblib.a files. The .a suffix indicates that the
           file is static, that is, nonshared.  Use this
           option if you want nonshared library bindings for
           linking.

           -Bsymbolic forces symbols to be resolved within a
           shared library if possible, even when a symbol is
           already defined elsewhere. For an explanation of
           -Bsymbolic, see the ld(1) man page.

           This option and its arguments are passed to the
           linker, ld.  If you compile and link in separate
           steps and are using the -Bbinding option, you must
           include the option in the link step.

           Warning:

           Never use -Bsymbolic with programs containing C++
           code, use linker scoping instead. See the C++
           User's Guide for more information on linker scop-
           ing. See also the -xldscope option.

           With -Bsymbolic, references in different modules
           can bind to different copies of what is supposed
           to be one global object.

           The exception mechanism relies on comparing
           addresses. If you have two copies of something,
           their addresses won't compare equal, and the
           exception mechanism can fail because the exception
           mechanism relies on comparing what are supposed to
           be unique addresses.
于 2011-08-20T11:42:16.693 に答える
0

オブジェクトは、必ずしも全体がリンクされたブロックであるとは限らないことに注意してください。コードによって参照されるかどうかに応じて、最終的な .exe に配置できる個別のセクションにシンボルを配置する方法があります。(-gc-sections リンカー オプション、および関連するセクション生成 gcc オプションを検索します)

セクションが使用されていない場合、これは単にマイクロ最適化されていない可能性があります。

于 2011-10-01T11:46:35.207 に答える