IGINブルネイ/syasudaの日記(MT版)

共有オブジェクトのprelinkをご存知でしょうか。Windowsでいえば、DLLのrebaseです。

共有オブジェクトは、同じアドレス空間にロードされますので、アドレスが被ってはいけないのです。なので、複数の共有オブジェクトをロードする場合、アドレスをずらしてロードすることになります。

で、その処理が重いので、あらかじめやっておいたらええじゃないかというのがprelinkだというわけです。

これによって、多数の共有オブジェクトをリンクする実行バイナリの起動時間が短縮される効果があると言われています。

さて、短縮される時間はアドレスをずらす”リロケーション(再配置)”とシンボルの突合せの２つの合計と考えられます。

シンボルの突合せは、共有オブジェクト特有の話ではありません。スタティックリンクでも、同じ処理が実行されます。つまり普段"リンク"と呼んでいる処理です。

そうすると思い出すのが、ldの高速化パッチです。場合によってはリンクにかかる時間が10分の1になるというのなら、共有オブジェクトのリンクも同じように高速化されるはずです。

例えば、リロケーションとシンボルの突合せにかかる時間が半分ずつだとしたら、実行バイナリのロードにかかる時間が、高速化パッチで半分強5分の1になるということではないでしょうか。

少なくともどちらもシンボル数に比例しそう(うまいこと実装してもO(log n))なので、余程特殊な場合で無い限り、効果が期待できると思うのですが。

逆に言うと、prelinkなどという面倒なものを導入する前に、ld-linux.soを高速化する方が汎用性があるような気がしてなりません。prelinkはバイナリをいじるので、いくら可逆な処理でいつでも元に戻せるとは言っても、心配な場合は心配です。

で、binutilsの最新版のソース(2.18)を眺めて2.16と見比べて、パッチを嘗め回しているのですが、すでに取り込まれているのかどうかさえ、さっぱり分かりません。たぶん気合が足りないのでしょう。ちなみに、2.16のelfc.はどうやら2.18のelflink.cに相当するようです。

リンク

prelinkの初心者用説明資料

CE Linux JapanTechnicalJamboree16

Summarizing Dynamic linking, part 3

Session for beginers

by Tetsuyuki Kobayashi (Aplix)

MIPSもprelinkに対応しておられるようで。

LD_DEBUGによるロード処理のデバッグなどについても説明があります。

挙げられている参考図書