0

まず最初に、過去数日間に投稿された私の質問に従わなかった皆さんに謝罪します。-ffunction-sectionsと-fdata-sectionsに関連する質問をしていたので、これは少し繰り返しに聞こえるかもしれませんが、これは同じ行にあります。それらの質問とその回答は私の問題を解決しなかったので、ここで完全な問題を述べ、SOの専門家にそれについて熟考させることが最善であることに気づきました。以前にそうしなかったことをお詫びします。

だから、ここに私の問題があります:

私は多くの機能を提供する静的ライブラリのセットを構築します。これらの静的ライブラリは、多くの製品に提供されます。すべての製品が私のライブラリによって提供されるすべての機能を使用するわけではありません。問題は、ライブラリのサイズが非常に大きく、製品がそれを縮小することを望んでいることです。主な目標は、ライブラリ自体のサイズではなく、最終的な実行可能ファイルのサイズを減らすことです。

さて、調査を行ったところ、ソースファイルに4つの関数があり、そのうちの1つの関数だけがアプリケーションで使用されている場合、リンカーは残りの3つの関数をすべて最終実行可能ファイルに含めることがわかりました。同じオブジェクトファイルに属します。さらに分析したところ、-ffunction-sections、-fdata-sections、および-gc-sections(これはリンカーオプションです)によって、1つの関数のみがリンクされることが保証されることがわかりました。

しかし、私の制御が及ばないいくつかの理由でこれらのオプションは現在使用できません。

リンカが厳密に必要な関数のみをリンクし、同じオブジェクトファイル内にある場合でも他のすべての関数を除外することを保証できる他の方法はありますか?

問題に対処する他の方法はありますか?

注:コードはレガシーコードであり、大きなものであるため、コードの再編成はほとんど除外されています。

ここでは主にVxWorksとGCCを扱っています。

助けてくれてありがとう!

4

1 に答える 1

3

最終的に、必要な関数のみが確実にリンクされるようにする唯一の方法は、ライブラリ内の各ソース (オブジェクト) ファイルが 1 つの関数シンボル (ファイルごとに 1 つの (可視) 関数) のみをエクスポートするようにすることです。通常、常に一緒に使用されるいくつかの関数をエクスポートするファイルがいくつかあります。たとえば、パッケージの初期化関数とファイナライズ関数です。また、ソース (オブジェクト) ファイルの外部に表示する必要のない、エクスポートされた関数によって使用される関数がよくありますstatic

Plauger の「The Standard C Library」を見ると、ファイルが 4 行の長さ (1 つのヘッダー、1 つの関数行、開き中かっこ、1 つの行のコード、および右中括弧)。


ジェイは尋ねました:

大きなプロジェクトの場合、ファイルが多くて管理が大変になりませんか?また、このモデルに従っているオープンソース プロジェクトはあまり見当たりません。OpenSSL はその一例です。

広く使われているとは言いませんでしたが、そうではありません。ただし、バイナリが最小化されていることを確認する方法です。コンパイラ (リンカ) は最小化を行いません。大規模なプロジェクトでは、通常はすべて一緒に使用される密接に関連する関数が 1 つのソース ファイルにグループ化されるように、ソース ファイルを設計します。たまにしか使わない関数は、別のファイルに配置する必要があります。理想的には、めったに使用されない関数は、それぞれ独自のファイルにある必要があります。それができない場合は、少数のファイルを小さな (ただし最小ではない) ファイルにグループ化します。そうすれば、めったに使用されない関数の 1 つが使用された場合でも、限られた量の余分な未使用コードがリンクされるだけです。

ファイルの数については - はい、支持されている手法は多くのファイルを意味します。多くのファイルを管理 (名前付け) する作業負荷と、最小限のコード サイズのメリットを比較検討する必要があります。自動ビルド システムにより、ほとんどの問題が解消されます。VCS システムは多くのファイルを処理します。

もう 1 つの方法は、ライブラリ コードを共有オブジェクトまたはダイナミック リンク ライブラリ (DLL) に入れることです。次に、プログラムは共有オブジェクトとリンクします。共有オブジェクトは一度だけメモリにロードされ、それを使用するプログラム間で共有されます。(一定でない) データは、プロセスごとに複製されます。これにより、ディスク上のプログラムのサイズが縮小されますが、ロード プロセス中のフィックスアップが犠牲になります。ただし、実行可能ファイルのサイズを気にする必要はありません。実行可能ファイルには共有オブジェクトは含まれません。また、ライブラリを使用するメイン プログラムを再コンパイルせずに、ライブラリを更新することもできます (注意が必要です)。共有ライブラリが人気がある理由の 1 つは、実行可能ファイルのサイズの縮小です。

于 2010-11-26T05:10:43.800 に答える