「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。

ソフテックだより（発行日順）のページへ
 ソフテックだより技術レポート（技術分野別）のページへ
 ソフテックだより現場の声（シーン別）のページへ

ソフテックだより第１５１号（2011年12月7日発行）
技術レポート

「GNUコンパイラコレクションを使用したマイコンソフトウェア開発」

1. はじめに

近年、ARM系マイコンの普及などに伴い、様々なCPUをターゲットとしてマイコンソフトウェアの開発を行う機会が増えてきました。マイコンソフトウェア開発では、一般的にCPUベンダが提供する専用の統合開発環境を使用することが多いですが、CPUターゲットが変わる度に新たな環境を構築し、かつ、それを長期的にメンテナンスしていくことには、それなりの労力とコストを要します。

また、近年のマイコンソフトウェア開発では、効率化のために既存のソフトウェアを継承した流用開発、派生開発といったものが一般的になりました。一方で、ハードウェア性能の向上や、部品入手性の問題から、CPUを含めたハードウェアの見直しは定期的に行われるため、CPUターゲットを変更した流用開発、派生開発では、必然的に開発環境も入れ替えなければいけない、といった状況が発生してしまいます。

このような場合に、CPUターゲットが変わっても同じ環境でソフトウェア開発ができるマルチCPU開発環境が威力を発揮します。今回取り上げるGCC（GNU Compiler Collection：グニューコンパイラコレクション）は、ARM、Blackfin、SH、V850など様々なCPUアーキテクチャに対応したコンパイル環境です。GCCの最大の特徴は、GPL（General Public License）に基づくフリーソフトウェアである点で、作成元のFree Software Foundation, Incによりそのソースコードも公開されています。最近は、マイコンでの使用を前提としたフリーの組み込みOSやプロトコルスタック、ミドルウェアソフトといったものも増えていますが、GCCが特定のCPUベンダに依存しないフリーのコンパイラであるという点などから、GCCでのコンパイルを前提としてソースコードが提供されるケースも増えています。これらのフリーソフトウェアの利用を検討されたことがある方は、一度はGCCに触れた経験があるのではないでしょうか。

今回のソフテックだよりでは、GCCの活用方法について、弊社での開発環境構築事例も含めて簡単に紹介したいと思います。

2. GCCを使用した開発のメリット・デメリット

GCCを利用すると良いことばかりかというと、当然、そうではありません。CPUベンダが提供する専用コンパイラと比べた場合の一般的なメリット・デメリットについて、ざっくりと表1にまとめてみました。

No.	比較項目	GCC	専用コンパイラ
1	対応言語	C、C++、Objective-C、Fortran、Java、Ada、Goなど。	C、C++のみの場合が多い。
2	対応ＣＰＵ	ARM、Blackfin、H8、M32R、PowerPC、SuperH、V850など。	互換性のあるアーキテクチャCPUのみに限定される場合が多い。
3	コード効率	CPUに依存しない汎用性を重視しているため、専用コンパイラと比べて劣るとされる。	特定のCPUに最適化されているためコード効率はよい。
4	コンパイラソース	GPLライセンスに基づくオープンソース。	ソースは非公開。提供元によってメンテナンスされる。
5	統合開発環境（IDE）	代表的なものとしてEclipseがあるが、Eclipseをベースとした派生IDEもいくつか存在する。デバッガは標準でGDB（GNU Debugger）を使用可能であり、JTAG ICEなどをターゲットと接続してデバッグできるほか、ターゲットを必要としないシミュレータデバッグ機能も有する。	予めコンパイラとセットになって配布される場合が多い。デバッガは標準で付属のものか、サードパーティー製品を使用可能。最近はシミュレータ機能を標準で具備しているものも多い。
6	開発ホスト環境	LinuxなどのUNIX系OS、Windows OSで使用可能。	Windows OSのみの場合が多い。
7	ライセンス（費用）	フリー。なお、GCCで生成したオブジェクトはGPLに該当しない。GPLに基づくライブラリとリンクした場合にはＧＰＬが適用される。	無償評価版が提供される場合もあるが、基本的には有償版を購入する必要がある。

表1. GCCとCPUベンダ提供専用コンパイラの比較

GCCのメリットとしては、多様な言語、CPUに対応している点がやはり大きいと思います。また、無償で入手できるため、手軽にソフト開発できる点も見逃せません。コンパイラの生成コード品質については、何を重視するか（オブジェクトサイズ、実行速度など）で見解が分かれますので、一概には比較できません。製品サポートという意味でも、”ソースが公開されているためGCCのほうが安心”と考えるのか、それとも、”有償でも一定のサポートを受けられるほうが安心”と考えるかは、立場によって評価が分かれる点です。いずれにしても、GCC利用に際しては、そのメリット・デメリット（リスク）をよく見極めたうえで選定していただく必要があります。

3. Windows環境でCygwinを使用した開発

GCC はもともとLinux OSとの親和性が高いですが、Windows環境でも利用することができます。GCCを使用したWindowsでの開発環境構築と注意点について、以下に説明したいと思います。

3-1. Cygwinのインストール

GCCをWindows環境で使用するのに、最も手っ取り早い方法として、RedHat社が提供するCygwin（シグウィン）を使用する方法があります。Cygwinは、Windows環境でUNIX環境を再現できるフリーソフトで、RedHat社のCygwinサイト（http://www.cygwin.com/）からsetup.exeをダウンロードすることができます。Cygwinの起動画面を以下に示します。GCCのインストールはこのCygwin画面から行います。

Cygwin起動時の画面です。コマンドは何も入力していません。
図1. Cygwin起動画面

3-2. GCCのインストールとバージョン

GCCでビルドを行うために最低限インストールしなければならないパッケージは、binutils、gcc（またはgcc-core）、newlibの3つになります。それぞれの機能は以下の通りです。

binutils: ：アセンブラ、リンカなどのユーティリティツール
gcc: ：コンパイラ
newlib: ：標準Cライブラリ

binutils、gccはGNUプロジェクトのサイト（http://www.gnu.org/）、newlibはRedHat社のサイト（http://sources.redhat.com/newlib/）からそれぞれ入手可能です。なお、GDBでデバッグを行う場合は、GDBもインストールする必要があります。

詳細なインストール手順についての説明はここでは割愛しますが、インストール時に注意すべき点として、binutils、gcc、newlibのバージョン選択があります。GCCに関しては、常に最新バージョンを使用するのがよいとは限りません。使用するターゲットCPUによっては、各パッケージのバージョンを変更するだけで、コンパイルすら通らなくなるということが普通に起こります。マイコンソフトウェア開発においてリスク回避を最優先とする場合は、特別な理由がない限り、実績あるバージョンのGCCを使用するのが無難だと思います。

3-3. Makefileとldファイル（リンカスクリプト）について

統合開発環境を使用せずにCygwinでビルドを行う場合は、コンパイルオプションやセクション指定などを行うためにMakefileやldファイル（リンカスクリプト）を直接編集する必要があります。

Makefileでは、プログラミング言語の定義、インクルードパスの指定、コンパイルオプションの定義、ライブラリのインクルード指定、ロードモジュールファイルの出力形式・・・などの設定を行います。ここでは設定内容の詳細な説明は省略しますが、コンパイルオプションを例にとってみても、デバッグ情報の出力形式（-gstabs：stabs形式、-gcoff：COFF形式、-gdwarf-1：DWARFバージョン1形式、-gdwarf-2：DWARFバージョン2形式など）や最適化オプション（-O0：最適化なし、-O1：レベル1最適化、-O2：レベル2最適化、-O3：レベル3最適化、など）の指定など、様々な指定が可能となっていますので、用途や条件に応じて最適な設定を選択してください。なお、ターゲットCPUとGCCバージョンの組み合わせによっては、対応していないオプション指定もありますので、注意が必要です。

ldファイル（リンカスクリプト）では、.text（プログラム領域）、.rodata（const領域）、.data（初期値付き変数領域）、.bss（初期値なし変数領域）などのセクションアドレスを指定します。また、モトローラSレコードファイル（.srec、.mot）、インテルHEXファイル（.hex）などロードモジュールの出力アドレス指定もこのファイルで行います。ユーザーが任意のセクションを作成し、そこに変数や関数を配置したい場合は、ソース上でsection属性を指定して対応します。たとえば、.versionという名前のセクションにc_Versionという変数を配置したい場合は、以下のようなコードを記述し、ldファイルで.versionの配置アドレスを指定すればOKです。

const char c_Version __attribute__ ((section (".version")));

3-4. Cygwinでのビルド実行

統合開発環境を使用しない場合は、マイコンソフトウェアのビルドもCygwinから実行します。WindowsのGUI環境に慣れ親しんでいると、コマンドライン入力に戸惑う方もいるかもしれません。しかし、GCCのビルド実行に関しては、使用するコマンドが数えるほどしかないので、おそれるほどのことはないでしょう。以下にソフトウェアビルド時に使用する主なコマンドの一覧をまとめます。

コマンド	入力例	説明
cd	ｃd project/gcc	指定パスにカレントディレクトリを移動します。ビルド実行の際には、ビルドルールが記載されたMakefileのディレクトリに移動する必要があります。なお、Cygwinのインストール先をデフォルト指定から変更していなければ、Cygwin起動直後のルートディレクトリは、「C:\cygwin\home\(ユーザー名)」となっています。
make clean	make clean	makeで作成された中間ファイル、アプリケーションなどを削除します。削除対象となるファイルはMakefile記載内容によります。リビルドを行いたい場合、makeの前に本コマンドを実行します。 ※本コマンドはmakeの疑似ターゲットコマンドです。Makefileに定義がない場合は実行できません。
make depend	make depend	ビルドに必要な依存関係ファイルを自動生成します。生成対象となるファイルはMakefile記載の内容によります。 ※本コマンドはmakeの疑似ターゲットコマンドです。Makefileに定義がない場合は実行できません。
make	make	カレントディレクトリに存在するMakefileのビルドルールに従い、ビルドを実行します。 makeを実行すると実行結果がばらばらとCygwinのWindowに出力されます。実行結果の中にはWarningなどの情報が含まれているため、ビルド後には一通りチェックしたい内容です。しかし、Windowの出力行数には上限があるため、一定行数を超えると過去の出力を参照できない場合があります。そのような場合は、出力結果をテキストに出力するオプションコマンド「>&」を使用すると便利です。具体的には「make >& log.txt」のように入力すると、Makefileと同じディレクトリに出力結果が「log.txt」というファイル名で保存されます。

表2. ビルド時に使用するコマンド

3-5. ソースファイルの文字コードについて

GCCでのコンパイルを前提としたオープンソースのC/C++言語ソフトウェアで日本語を扱うものの中には、ソースファイルの文字コードがEUC（Extended UNIX Code）となっているものがあります。一方、Windows環境で日本語を扱う組み込み系のC/C++言語ソースファイルは、Shift-JISが一般的です。GCCはgcc-3.4.3以降でShift-JISコードのコンパイルが可能になりましたが、それまではEUCのみの対応となっていました。
Windows環境での開発で、以下のケースに該当する場合は、EUCソースファイルの扱いに注意が必要です。

ソースファイルをMicrosoft VSS（Visual Source Safe）で管理したい。
VSSでEUCを扱うと、”ソース比較を使用できない”、”改行コードが自動でCR+LFに変換される”、などの問題が発生する可能性があります。EUCソースファイルの管理には、VSSよりCVS（Concurrent Versions System）やSVN（Subversion）のほうが向いています。
同じソースファイルをVisual C++ 6.0でもビルドしたい。
ソースファイル内で日本語文字列を扱うと、”特定の文字コード使用時にコンパイルできない”などの問題が発生します。ソースファイルをShift-JISコードに変換し、GCCをShift-JIS対応バージョンとするなどの対策が必要です。

4. 開発環境構築例

GCCでの具体的な開発環境構築事例についてご紹介したいと思います。先に説明したようにGCCは、専用コンパイラの場合と違い、統合開発環境やデバッグ環境の選択に自由度があります。デバッグ環境については、ＪＴＡＧ ICEを使用するか、GDBを使用するのかなどでデバッグ効率も変わってきますので、開発の状況に応じて最適なものを選択してください。
以下に、弊社の開発で実際に使用した開発環境構築例を参考として記載します。

4-1. SH-2Aマイコンターゲットの例

項目	分類1	分類2	補足/注意点
ホストOS	Windows 2000 Pro		Cygwin 1.7.1-1 (setup 2.693)をインストール。
コンパイラ	GCC	gcc-core-2.95.3 binutils-2.14 newlib-1.9.0
ターゲットCPU	SH-2A [ルネサスエレクトロニクス（株）]
デバッガ	ハードウェア	PALMiCE 3 [（株）コンピューテックス]
デバッガ	ソフトウェア	CSIDE for PALMiCE3 SuperH Ver 6.04.01 [（株）コンピューテックス]	GCCのデバッグ情報コンパイルオプションはELF/DWARFバージョン2形式（-gdwarf-2）とした。

表3. SH-2Aターゲット開発環境構築例

SH-2Aターゲット開発環境のイメージ図です。
図2. SH-2Aターゲット開発環境イメージ

4-2. V850ESマイコンターゲットの例

項目	分類1	分類2	補足/注意点
ホストOS	Windows 2000 Pro		Cygwin 1.7.1-1 (setup 2.693)をインストール。
コンパイラ	GCC	gcc-core-2.95.3 binutils-2.14 newlib-1.9.0
ターゲットCPU	V850ES [ルネサスエレクトロニクス（株）]
デバッガ	ハードウェア	MINICUBE [ルネサスエレクトロニクス（株）]
デバッガ	ソフトウェア	PM+ v330 ID850QB v350 QBProgramer v224 [ルネサスエレクトロニクス（株）]	PM+はGCCに正式対応していない。GCCのデバッグ情報コンパイルオプションをELF/DWARFバージョン1形式（-gdwarf）としたところ、最適化によるブレークポイントの位置ずれなどはあるが、かろうじてCソースファイルレベルでのデバッグが可能であった。

表4. V850ESターゲット環境構築例

V850ESターゲット開発環境のイメージ図です。
図3. V850ESターゲット開発環境イメージ

5. 最後に

今回は、GCCについて取り上げましたが、いかがだったでしょうか。最近は、組み込みソフト開発においてもLinux OSやフリーソフトウェアに触れる機会が以前より増えました。今回取り上げたGCCやCygwinといった開発環境はそれらに触れるきっかけとなるツールであり、今後の組み込みソフト開発においても、無視できない技術であると感じています。

（T．S．）

[参考文献]

岸哲夫: 「フリー・ソフトウェアで学ぶＣ言語プログラミング」　Interface Apr. 2006
中村建真: 「フリー開発環境のインストールと設定」　Interface May. 2010