-Bsymbolic-functionsの使用には欠点がありますか？

Question

私は最近、リンカオプションGNU ldの中に「-Bsymbolic-機能」を発見：

-Bsymbolic 
    When creating a shared library, bind references to global symbols to the 
    definition within the shared library, if any. Normally, it is possible 
    for a program linked against a shared library to override the definition 
    within the shared library. 

    This option is only meaningful on ELF platforms which support shared libraries. 

-Bsymbolic-functions 
    When creating a shared library, bind references to global function symbols 
    to the definition within the shared library, if any. 

    This option is only meaningful on ELF platforms which support shared libraries. 

これはGCCオプション-fvisibility=hiddenの逆のようだ、という点ではなく、他に参照される関数の輸出を防止その関数へのライブラリー内部参照が、別の共用オブジェクトのエクスポートされた関数にバインドされないようにします。私は-Bsymbolic-functionsが機能のためのPLTエントリーの作成を妨げることを自分自身に知らせました。これは素晴らしい副作用です。

1. しかし、私は、ライブラリーの個々の関数定義のための-Bsymbolicを上書きするように、おそらくこれ以上の細かな制御があるかどうかを疑問に思いました。

2. -Bsymbolic-functionsの落とし穴に気づくべきですか？ -Bsymbolicが例外を壊すので、私はそれを使用する予定です（typeinfoオブジェクトへの参照が統一​​されていないようにすると思います）。

ありがとう！

Answer 1

私はちょうどそれのためにタンブルウィードバッジを獲得したので、自分の質問に答える...と私はその後

を発見しかし、私は-Bsymbolicを上書きするように、このオーバー細かな制御がおそらく存在するかどうかを疑問に思いましたライブラリの個々の関数定義について。

はい、正確に行いオプション--dynamic-listは

私は-Bsymbolic-functionsを使用して、任意の落とし穴を認識する必要があることがありますか？私はそれを使用することを計画しています。なぜなら、-Bsymbolicが例外を壊すからです（typeinfoオブジェクトへの参照が統一​​されていないようにすると思います）。

私はそれ以上のことを見て、問題はないようです。 libstdC++ライブラリは明らかにそれを行うか、少なくともそれを考慮しましたが、operator newを統合するためには--dynamic-list-cpp-newを追加しなければなりませんでした。（複数のアロケータ/デアロケータがプログラムに混在する問題を防ぐためです。 Ubuntuはデフォルトでそれを使用するか、またはそれを使用しています。これは、いくつかのパッケージとの競合を引き起こすようです。しかし全体的にはうまくいくはずです。

Answer 2

副作用がある場合があります。文書化されたもの： https://bugs.launchpad.net/ubuntu/+source/xfe/+bug/644645 私はこのような場合があるので、これについてさらに詳しく知りたいと思います。

Answer 3

glibcを-Bsymbolic-functionsでビルドすることはお勧めしません。ここに私が得た結果があります：

Core was generated by `/home/lano1106/dev/packages/glibc/repos/core-i686/src/glibc-build/elf/ld-linux                .'. 
Program terminated with signal 11, Segmentation fault. 
#0 0x400a3e90 in _int_free() 
    from /home/lano1106/dev/packages/glibc/repos/core-i686/src/glibc-build/libc.so.6 
(gdb) where 
#0 0x400a3e90 in _int_free() 
    from /home/lano1106/dev/packages/glibc/repos/core-i686/src/glibc-build/libc.so.6 
#1 0x4016b94b in __libc_dlsym() 
    from /home/lano1106/dev/packages/glibc/repos/core-i686/src/glibc-build/libc.so.6 
#2 0x4004c2c7 in __gconv_find_shlib() 
    from /home/lano1106/dev/packages/glibc/repos/core-i686/src/glibc-build/libc.so.6 
#3 0x40042320 in find_derivation() 
    from /home/lano1106/dev/packages/glibc/repos/core-i686/src/glibc-build/libc.so.6 
#4 0x40042889 in __gconv_find_transform() 
    from /home/lano1106/dev/packages/glibc/repos/core-i686/src/glibc-build/libc.so.6 
#5 0x400d6f00 in __wcsmbs_load_conv() 
    from /home/lano1106/dev/packages/glibc/repos/core-i686/src/glibc-build/libc.so.6 
#6 0x400c86f6 in mbrtowc() 
    from /home/lano1106/dev/packages/glibc/repos/core-i686/src/glibc-build/libc.so.6 
#7 0x08048914 in ??() 
#8 0x00000000 in ??()