問題タブ [linker-scripts]

より深いリンクプロセスとリンカースクリプトを理解しようとしています... binutils doc を見ると、いくつかのコマンドを追加することで改善された単純なリンカースクリプトの実装が見つかりました:

私のプログラムは非常に単純なプログラムです:

今、私は実行可能ファイルを構築しようとしました:

しかし、実行しようとするprogと、SIGKILL起動中にエラーが発生します。プログラムがコンパイルされ、コマンドでリンクされると、次のことがわかります。

最終的な実行可能ファイルは、 のような他のオブジェクト ファイルの生成物でもありますが、crt1.o私の場合はどうでしょうか。このリンカー スクリプトを使用する正しい方法はどれですか?crti.ocrtn.o

フラッシュベースのマイクロコントローラーで実行するコードをリンクすることになっている次のリンカースクリプトがあります。uCには、アドレス0x0にフラッシュがあり、0x40000000にRAMがあります。データセクションをフラッシュに入れたいのですが、データセクションへのアクセスがRAMで行われるようにプログラムをリンクします。重要なのは、コントローラーの起動時に、フラッシュから適切なRAMの場所に手動でコピーすることです。

上記のコードは、次の出力を生成します。

これは、フォームの配列を表します

問題は、それが0x40000000にリンクされており、私が望んでいたフラッシュ領域ではないことです。LDマニュアルで説明されているように、リンカースクリプトのAT> flash部分で、フラッシュへのリンクを指定することを期待していました。

http://sourceware.org/binutils/docs/ld/Output-Section-Attributes.html#Output-Section-Attributes

そして、これが私のld呼び出しです：

ありがとう。

ALIGN キーワードはリンカー スクリプトで何をしますか? リンカ スクリプトに関する多くのチュートリアルを読みましたが、ALIGN が実際に何をしているのか理解できません。誰でも簡単に説明できますか。ありがとう！

私はcortex-m3チップに取り組んでいます。bss セクションの初期化されていない配列を使用して、ソース コードでスタック スペースが予約されていました。使用したリンカー スクリプトは次のとおりです。

SRAM 領域の先頭にスタックのセクションを割り当てようとしているので、使用法違反によるスタック オーバーフローを検出できます。

.stack という名前のセクションを追加しました。

リンクはエラーや警告なしで行われますが、問題は __stack_end が SRAM 領域ではなく FLASH 領域にあることです。

__attribute__((section("name"))) で指定された別のセクションを使用できることはわかっていますが、リンカースクリプトで処理できればよいと思います。

SRAM 領域に空のセクションを作成するにはどうすればよいですか?

短編小説。プラットフォーム/アーキテクチャ/ベンダーを変更した場合に、何をすべきかわからずにゼロにとらわれないように、優れたリンカースクリプトを作成する方法を学びたいと思います。私はそれを理解するのと同じくらい、仕事の難しさには関心がありません。

私は、いわば、STMの32ビットCortex-M3チップでプログラミングおよび開発するためのベースまたはスケルトンを作成するための一種のプロジェクトを開始しました。jsiei97の助けを借りてSTM32F103RBから始めて（私もTI Stellaris LM3S828を持っていますが、それは別の問題です）、ライセンスされたIDEは必要ありません。私は学生なので、ほとんどの学生はそのようなものを買う余裕がありません。

ODevやEclipseプラグインなどがあることを理解しています。さまざまなブログ、ウィキ、ドキュメント/マニュアルページを読んだことがあります。ほとんどのプロジェクトでは、リンカースクリプトが提供されており、定義されている理由と場所についての説明はほとんどありません。

STM32用にarm-none-eabiツールチェーンをコンパイルしましたが、ハングアップするのはリンカースクリプトです。CodeSourceryにも1つ必要です。gnuのマニュアルページを読んだ後、それらを作成する方法とその構文の基本的な概念はありますが、明らかな.text、.bss、および.data以外のさまざまな追加セクションをどこから始めるかについての手がかりがありません。 。

初歩的なバージョンを作成しましたが、セクション定義を要求するリンクエラーが発生し、そこで行き詰まります。私はそれらを定義する方法を知っていますが、私がしていることが正しいかどうかを知ることは問題です。

VIMがシンタックスハイライトを使用するためのリンカースクリプトの通常のサフィックスは何ですか？

__exidx_start = .;こんにちは、ラベルの値をロケーション カウンターの値に設定するコード " " を見つけたリンカ スクリプトがあります.。このラベルは、同じリンカー スクリプト内のどこにも使用されていません。

最初の行の数行下に同様のラベルが定義されており、同じように定義されています " __exidx_end = .;"。

これらの 2 つのラベルはセクション.textと.rodataセクションの境界ですが、リンカー スクリプトで使用されていない場合、なぜこれら 2 つを定義するのかわかりません。

リンカ スクリプトでシンボルを定義することの使用は何だろうと思っています。リンカー スクリプトを使用してさまざまなセクションを配置することは理解できますが、スクリプトで新しいシンボルを定義することは私にはわかりません。2 つの新しいシンボルを定義するリンカー スクリプトを使用する記事を読んでいましたが、それらのシンボルはリンカー スクリプトまたは記事の他の場所では参照されていませんでした。以下に示すように、bss セクションで sbss および ebss シンボルを使用する例を次に示します。

etext 、 dataEnd など、頻繁に使用される他のシンボルもあります。スクリプトのどこにも参照されていない場合に、そのようなシンボルを定義する方法を説明してください。

LDのマニュアルには、このKEEPコマンドが何をするかが説明されていません。以下は、KEEP. KEEPコマンドは で何をしldますか?

私のユースケースは次のとおりです。

• Makefileベースのプロジェクトに付属している典型的なSDKを使用しています
• リンカーにはパッチが適用されたgccがあると思います。gcc--versionは4.3.4を与えます
• SDKはリンカースクリプトを定義します（Linker.ldと呼びます）
• Linker.ldには、リンクされたELFイメージのさまざまなセクションの絶対アドレスを定義するLinkerMemMap.cfgが含まれています。
• SDKは、Makefile（GNU Make 3.81）に基づくアプリケーションテンプレートを提供し、それ自体を作成します
• SDKが提供するMakefileテンプレートでは、gccが呼び出されると、次のようにLinker.ldに-Tコマンドラインオプションが提供されます。

gcc $(OBJS) -l$(Lib1) -l$(Lib2) -nostdlib -lgcc -L$(library_path) -g -msmall-mode -mconst-switch-tables -mas-mode -mno-initc -Wl,--start-group,--end-group,-T,$(PATH_TO_Linker.ld),--gc-sections -o$(OUTPUT).elf

私の要件は次のとおりです。

• Linker.ldで定義されているセクションを使用し、LinkerMemMap.cfgに従ってメモリマップを使用したいのですが、LinkerMemMap.cfgで定義されている特定のシンボル（SYMBOL_RAM_STARTと呼びます）を微調整します。

何が機能するか：

• 最終的なELFイメージをリンクする前に、makefileで試しましたが、LinkerMemMap.cfg（Linker.ldに含まれています）をビルドディレクトリにコピーし、パッチを適用してSYMBOL_RAM_STARTを再定義します。これは、リンカーがリンカースクリプトと、現在のフォルダー内のリンカースクリプトに含まれるファイルを最初に検索するときに機能します。

しないこと：

• 残念ながら、私たちの利害関係者は、上記の方法はリスクが高く複雑すぎて理解できないと考えています。リンカコマンドラインのシンボル値を次のように上書きしたいと思います。

  1. gcc $(OBJS) -l$(Lib1) -l$(Lib2) -nostdlib -lgcc -L$(library_path) -g -msmall-mode -mconst-switch-tables -mas-mode -mno-initc -Wl,--start-group,--end-group,-T,$(PATH_TO_Linker.ld),--gc-sections,--defsym=SYMBOL_RAM_START=$(VALUE_TO_OVERRIDE) -o$(OUTPUT).elf

  2. gcc $(OBJS) -l$(Lib1) -l$(Lib2) -nostdlib -lgcc -L$(library_path) -g -msmall-mode -mconst-switch-tables -mas-mode -mno-initc -Wl,--start-group,--end-group,-T,$(PATH_TO_Linker.ld),--gc-sections --defsym=SYMBOL_RAM_START=$(VALUE_TO_OVERRIDE) -o$(OUTPUT).elf

  3. gcc $(OBJS) -l$(Lib1) -l$(Lib2) --defsym=SYMBOL_RAM_START=$(VALUE_TO_OVERRIDE) -nostdlib -lgcc -L$(library_path) -g -msmall-mode -mconst-switch-tables -mas-mode -mno-initc -Wl,--start-group,--end-group,-T,$(PATH_TO_Linker.ld),--gc-sections -o$(OUTPUT).elf

これらはいずれも、リンカーによって作成されたリンクされたイメージに影響を与えないようです。

• --defsymは、-Tを使用して指定されたlinkerscriptによって定義されたシンボルをオーバーライドできますか？
• 私がここで何を間違っているのか見てください。