シンボル情報の読み込み、設定、編集

シンボルファイル(シンボル情報)

シンボルファイルについては、以前、ファイルに関係して少しだけ話題にしましたが、ここでは、シンボル定義などまで含めた機能についてです。

シンボルというのは大雑把（言語による定義の違いなどもあるので大まかですが）にいうと名前です。メモリや定数などに名前を付けることで、扱いやすくするためにシンボルの機能で名前をつけます。

現在は、ソースレベルのデバッガが主流になってきていますので、「シンボリックデバッガ」などとあえてシンボルが使えるデバッガと主張されることもなくなっていますが、創生期には、シンボルが使えない所から始まって、シンボルが利用できるようになり、ソースファイルとの対応、さらに高度なデバッグ情報までできているようにと発展してきています。

シンボリックデバッグ、ソースレベルデバッグ

ICEなどでは、シンボリックデバッガやソースレベルデバッグという言葉が生きているように思いますが、PC用では当然で、あまり意味が無くなっているかも知れません(低レベルでは意味あると思いますが)。

ちなみにGoogleで"ソースレベル　デバッグ"を検索すると、日立のページが１番に表示されます。ページのタイトルは、「Ｃソースレベルデバッグができない」です。

　　▼日本語Google
　　　　http://www.google.co.jp/

シンボル(名前)をつけると、リンク(バインド)してメモリが再配置されても、意味のある名前でコードやデータメモリなどを指定することができるので、デバッグ作業が効率化できます。

　　▼ASII24 アスキーデジタル用語辞典「リンク」
　　　　３番目の意味になっていますね。
　　　　http://yougo.ascii24.com/gh/70/007024.html

デバッガの事前確認

現在は、ソースレベルデバッグが主流になったため簡単なシンボル情報ではなく、ソースとの対応まで含めたデバッグ情報をICEが読めないとシンボルすら読み込めない状態に陥ることがあります。特殊なプロセッサやカスタム化されたプロセッサなどでは、もしかしたら、ソースレベルはおろか、シンボリック・デバッグにすら、問題があるかもしれませんので、採用前にはしっかり確認することが肝要です。

マップ情報、リローケーション

初期のデバッガがサポートしていたシンボルファイルは、マップ・ファイルなどと呼ばれる、シンボル名と絶対アドレスが記載されただけの極単純な形式が主でした（書式は各種になりますが）。

この場合、デバッガは、アドレスとシンボルの記載された書式付のテキストを読み込めれば良いので、形式の異なるファイルなども簡単にサポートすることも可能ですし、ユーザーが書式変換してシンボルを加工するのも容易でした。

しかし、動的にメモリ配置される場合には、リローケーションが必要ですし、シンボルの属性、例えば、コードのアドレス、データのアドレス（と語長）などデバッグに有効な情報にするには、より高度な情報が必要になります。

　　※リローケーション　（メモリのロード時の再配置）
　　▼リロケータブル
　　　　ASCII24 アスキーデジタル用語辞典
　　　　http://yougo.ascii24.com/gh/05/000548.html

当然ソースレベルデバッグに対応したり、高級言語の変数タイプなどに対応するにつれて「高度」な情報が主になり、マップ・ファイルは出力することもできる程度の位置付けになってきます（これが有用な場合もありますが）。

変換ツールなどの手間を削減

デバッガで形式が異なるファイルをサポートするのも、内部の情報レベルまで異なるため、対応が難しくなり、おのずと、サポート・フォーマットもある程度限定されてきます。同時に、デバッグ情報の記録形式とその中に含まれる情報が多いため、ユーザーが簡単に変換するというわけにも行かなくなります。

そのため、ICE、デバッガのシンボルやデバッグ情報に何らかの工夫をする必要があるような事態が生じる場合(コンパイラ、リンカ、アセンブラ、デバッガなどのツールをメーカー混合利用するなど)、デバッグ情報出力するためのツールを作ることにパワーが必要になります。

メーカーによって、サードパーティ製の変換ツールで別のデバッグ情報を変換できたり、シンボルの埋め込みができたりする場合もありますが、メーカーのQ&Aなどにはっきりと「他のデバッグ情報は対応できません」などと明記されている場合がありますから、事前に検討して、ツールを選択するところまで含めて注意が必要です。

コンパイラやリンカを組み合わせる

近年では組み込み系も、高級言語を利用して開発する機器も少なくありませんが（普通という方が適切かもしれません）、CPUやDSPなどが高速化のために専用命令をそなえている場合、メーカーのコンパイラが高度に対応している場合を除けば、ネイティブな専用コードを利用したコードが生成されることはありません(クロス開発に注力されている場合などは)。

メーカー提供のコンパイラの場合にも、通常の実行に不可欠な制御やメモリ操作コードには対応していますが、DSP機能や並列実行の特殊命令などを積極的に利用したコード生成を行なうコンパイラは多くはありません。

基本的な実行コードが並列処理を基本としている場合には、並列処理のコードに対応したコード生成がされますが、特殊命令のような実装のプロセッサでは、アセンブラもしくは、インラインマクロのような機能による機械語コードの直接記述などが必要になります。

このような専用命令をアセンブラで実装する場合には、ツールを混合して実行モジュールを開発することになることも少なくありません。

混合方式の場合には、A社のアセンブラにB社のコンパイラ、デバッガのようにツールが１社で提供されているものを利用するとも限りませんので、デバッグ情報をデバッガが正しく読み込むことができるかが問題になります（それ以前に混合開発できるかも問題ですが）。

クロス開発とデバッガ

クロス・コンパイラを用いる場合にはアセンブラと高級言語で実行モジュールを作成することは問題なくできると思いますが、対応できるデバッガが少ない場合もあります(シェアの大きいプロセッサ、ICEは対応されているでしょうが、少し特殊になると...)。

高級言語で開発しているだけに、デバッガのデバッグ情報が高度な状態で互換されないと、デバッグ時には、十分な情報を利用できないということになり、かなり効率に影響する場合もあります。