組込み開発におけるGCCとリンカスクリプトの深淵：ハードウェア制約をねじ伏せるメモリ配置デザイン
こんにちは。テックリードの私だ。
日々の組込み開発において、「RAMが足りない」「特定の高速SRAMにクリティカルなISR（割り込みサービスルーチン）を常駐させたい」「フラッシュの特定セクタに永続的な校正値を焼き込みたい」といった、ハードウェアの物理的制約に頭を抱えた経験はないだろうか。
世の中の多くのチュートリアルは、「GCCを入れて、`make`を叩けばバイオグラフィが生成されます」といった入門レベルで止まっている。しかし、プロフェッショナルな現場で求められるのは、メモリマップを完全に支配し、リンカの挙動を意図通りにねじ伏せるスキルだ。
今回は、GCCとGNU ld（リンカ）が内部でどのようにセクションを解釈し、物理アドレスへマッピングしているのか。そのメカニズムの深部を紐解きつつ、実務で即座に使えるリンカスクリプトのベストプラクティスと、ソースコード側からの制御テクニックを伝授する。
—
1. リンカスクリプトの内部挙動：なぜ「セクション」の概念が必要なのか
コンパイラ（GCC）は、C言語のソースファイルを独立したオブジェクトファイル（`.o`）へとコンパイルする。この時点では、関数や変数が「どの物理アドレスに配置されるか」は一切決まっていない。決まっているのは、コード領域（`.text`）、初期化済みデータ領域（`.data`）、未初期化データ領域（`.bss`）といった論理的な属性（セクション）の分類だけだ。
リンカ（`ld`）の仕事は、これらバラバラのオブジェクトファイル群を集め、ターゲットマイコンの物理メモリマップ（SRAMやFlashの開始アドレスとサイズ）に従い、適切なアドレスへパズルピースのように配置していくことにある。
この配置のルールを記述するのがリンカスクリプト（`.ld`文件）だ。ここを曖昧にしていると、ブート時にデータが意図せぬ領域に上書きされたり、ハードウェア例外（HardFault）を引き起こす魔物のようなバグを生み出す原因になる。
—
2. 実務で役立つ！リンカスクリプトのベストプラクティス構成例
まずは、一般的なCortex-Mマイコンなどを想定した、実用的かつ拡張性の高いリンカスクリプトの構成例を見てほしい。
メモリ定義とセクション配置の記述 (`linker.ld`)
/ =================================================================オ
- メモリ領域の物理定義
- マイコンのデータシートに基づき、FlashとRAMの開始アドレスと容量を定義する
- ================================================================= /
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 512K / 読み込み・実行専用のフラッシュメモリ /
DTCM_RAM(rwx): ORIGIN = 0x20000000, LENGTH = 128K / 0待機サイクルの緊密結合メモリ（高速処理用） /
AXI_SRAM(rwx): ORIGIN = 0x24000000, LENGTH = 512K / 一般的なシステムSRAM /
}
/ =================================================================オ
- セクション配置の定義
- 入力セクション（.oファイル内）を出力メモリ領域にどう割り当てるかを指定
- ================================================================= /
SECTIONS
{
/ ベクタテーブルおよびプログラムコードはフラッシュの先頭に配置 /
.text :
{
. = ALIGN(4);
KEEP((.isr_vector)) / 割り込みベクタテーブルが最適化で消されないようKEEPで保護 /
(.text) / すべての通常のコードセクション /
(.text.) / 関数単位(-ffunction-sections)で分割されたコード /
(.rodata) / 読み取り専用定数データ /
(.rodata.)
. = ALIGN(4);
} > FLASH
/ 高速実行が要求されるクリティカルな関数を配置する独自セクション /
.fast_code :
{
. = ALIGN(4);
_sfast_code = .; / 転送元（Flash）からのコピー用シンボル定義 /
(.fast_code)
(.fast_code.)
. = ALIGN(4);
_efast_code = .;
} > DTCM_RAM AT > FLASH / VMA(仮想アドレス)=DTCM_RAM, LMA(ロードアドレス)=FLASH /
/ 初期値を持つグローバル・静的変数 /
.data :
{
. = ALIGN(4);
_sdata = .; / RAM上のデータ領域の開始位置 /
(.data)
(.data.)
. = ALIGN(4);
_edata = .; / RAM上のデータ領域の終了位置 /
} > AXI_SRAM AT > FLASH
/ 初期値を持たない変数（ゼロクリア対象） /
.bss :
{
. = ALIGN(4);
_sbss = .; / BSS領域の開始位置（起動時に0埋めする） /
(.bss)
(.bss.)
(COMMON)
. = ALIGN(4);
_ebss = .; / BSS領域の終了位置 /
} > AXI_SRAM
}
アーキテクトの解説：`AT > FLASH` の魔術
上記の `> DTCM_RAM AT > FLASH` という記述に注目してほしい。
これは VMA（Virtual Memory Address: 仮想アドレス） と LMA（Load Memory Address: ロードアドレス） の分離を行っている。
- LMA (FLASH): マイコンの電源を切っても消えないため、プログラムのバイナリにはこの領域にデータが書き込まれて格納される。
- VMA (DTCM_RAM): CPUが実際にコードやデータを読み書きするために実行時に存在すべきアドレス。
つまり、マイコン起動時のスタートアップコード（`crt0.c`等）において、LMA（Flash）にある `.fast_code` や `.data` の実体を、VMA（RAM）の領域へ `memcpy` によって転送する処理を書くことで、低速なFlashからではなく超高速なRAM上でコードを爆速実行することが可能になるのだ。
—
3. 属性（`__attribute__`）を駆使したソースコード側の制御
リンカスクリプト側でカスタムセクション（`.fast_code` など）を定義したら、次はC言語のソースコード側からそのセクションへ変数をピンポイントで送り込む必要がある。ここで `__attribute__` の出番だ。
特定のメモリ領域にデータを固定配置する実装例
include
/ 1. 通常のRAMではなく、特定の高速SRAM（DTCM）にクリティカルな関数を配置 /
__attribute__((section(“.fast_code”)))
void critical_motor_control_isr(void)
{
// 毎制御周期（例: 20kHz）で実行されるため、バスウェイトゼロのメモリで動かす必要がある
// ここにモータ制御のPWM計算ロジックなどを記述
}
/ 2. 不揮発性領域（Flashの特定セクタ）に配置するデバイス校正値・パラメータ /
/ 書き換え頻度が少なく、電源断後も保持しなければならない定数 /
const __attribute__((section(“.rodata.calibration”)))
uint32_t calib_sensor_offset = 0x12345678;
/ 3. 外部共有メモリ（DMA用バッファなど）に配置し、キャッシュ無効化を容易にする変数 /
__attribute__((section(“.bss.dma_buffer”), aligned(32)))
uint8_t dma_rx_packet_buffer[1024];
なぜこのテクニックが開発効率・品質を劇的に高めるのか？
1. リアルタイム性の限界突破:
モータ制御やデジタル電源などのハードリアルタイム処理において、コードがFlashのプリフェッチバッファミス（キャッシュミス）を起こすと、ジッタ（処理遅延の揺らぎ）が発生して制御系が不安定になる。クリティカルな関数だけを `__attribute__((section(“.fast_code”)))` でRAM上にスワップすることで、決定論的な実行時間を保証できる。
2. DMAとキャッシュコヒーレンシーの完全制御:
DMA（Direct Memory Access）を使う際、CPUキャッシュとRAMの間でデータ不整合（コヒーレンシー問題）が起きやすい。特定のバッファを専用セクションに追い出し、リンカスクリプト側で `aligned(32)` などのアライメントを強制することで、キャッシュメンテナン命令（`SCB_InvalidateDCache_by_Addr`など）の適用範囲を正確に制御できる。
—
4. チーム開発を加速させるコンパイラ・リンカオプションの作法
個人開発ならいざ知らず、複数人で組込みソフトウェアを開発する場合、「誰かのローカル環境ではビルドできるが、別の人の環境ではリンクエラーになる」といった環境依存のトラブルは絶対に避けなければならない。
プロジェクトのルートにある `Makefile` または `CMakeLists.txt` において、以下のGCCフラグを共通ルールとして強制すること。
GCCコンパイル・リンクオプションのベストプラクティス
CMakeでのセクション最適化フラグの強制設定例
target_compile_options(firmware PRIVATE
-ffunction-sections # 関数ごとに独立したセクション(.text.func_name)に分割する
-fdata-sections # 変数ごとに独立したセクション(.data.var_name)に分割する
-Wall -Wextra -Werror # 警告をすべてエラーとして扱い、品質のバラつきを排除する
)
target_link_options(firmware PRIVATE
-T${CMAKE_CURRENT_SOURCE_DIR}/linker.ld # 今回解説したカスタムリンカスクリプトの適用
-Wl,–gc-sections # 未使用の関数や変数を最終バイナリから完全に排除（デッドコード削除）
-Wl,-Map=${CMAKE_BINARY_DIR}/output.map # リンカマップファイルを出力させ、メモリ使用量を可視化する
)
テックリードからのアドバイス：`-Wl,-Map` を絶対に怠るな
`-Wl,-Map=output.map` を有効にすると、ビルド時に「どのオブジェクトファイルのどの関数が、どのアドレスの何バイト目に配置されたか」の全容がテキストとして出力される。
メモリが枯渇した際、どのモジュールが肥大化しているのかを直感的に暴き出すための最強の診断ツールとなる。CI/CDパイプライン上でこのマップファイルを解析し、ROM/RAMの使用率が閾値を超えたらビルドを落とす仕組みを構築しておくと、プロダクトの寿命が劇的に伸びる。
—
5. まとめ：ハードウェアを完全に手なずけろ
今回解説したリンカスクリプトのカスタマイズと `__attribute__` によるセクション制御は、単なる「コンパイルを通すためのテクニック」ではない。
- ハードウェアの物理特性（メモリの速度、容量、特性）とソフトウェアの論理構造を1対1で結びつける
- 意図しないメモリ破壊やジッタの発生源を、設計の段階で完全に遮断する
これこそが、一流の組込みエンジニアと、そうでないエンジニアを分ける境界線だ。
今日からあなたのプロジェクトでも、デフォルトのリンカスクリプトを脱ぎ捨て、ハードウェアの性能を極限まで引き出す真のメモリデザインを実装してほしい。コードが意図通りのメモリマップに美しく収まったとき、開発の本当の楽しさが実感できるはずだ。