JP3304995B2 - シンボリックデバッグシステム及びその方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、トランスレータベース
のソフトウェアコンパイルシステムで意味のあるシンボ
リックデバッグ情報を発生するコンピュータシステム及
び方法に関する。

【０００２】

【従来技術及びその問題点】図１は、従来のトランスレ
ータベースのコンパイルシステム１００の構造図／機能
フローチャートを示す。図１で、長方形はソフトウェア
モジュール／プロセスを表わし、長円形はソフトウェア
モジュール／プロセスの入力及び出力を表わす。

【０００３】図１に示すように、従来のトランスレータ
ベースのコンパイルシステム１００は、トランスレータ
１０６、コンパイラ１１４、リンカ１２８及びデバッガ
１２２を含んでいる。

【０００４】トランスレータ１０６は、ソースコード１
０２（例えば、Ｃ＋＋言語で書かれている）を中間ソー
スコード１１０（例えば、Ｃ言語で書かれている）に翻
訳する。コンパイラ１１４は、中間ソースコードをコン
パイルし、オブジェクトコード１２４及びコンパイラデ
バッグ情報１２６を発生する。オブジェクトコード１２
４及びコンパイラデバッグ情報１２６は、オブジェクト
コードファイル１１８に格納される。

【０００５】リンカ１２８は、オブジェクトコードファ
イル１１８を他のオブジェクトコードファイル１３４と
リンクして実行可能ファイル１３２を作製する。実行可
能ファイル１３２にはオブジェクトコード１２４及びコ
ンパイラデバッグ情報１２６が入っている。

【０００６】コンパイラデバッグ情報１２６は、これを
ソースコード１０２の誤りを突きとめて修正する（すな
わち、ソースコード１０２を「デバッグする」）のに使
用することができるので非常に重要である。特に、ユー
ザ（図１には示してない）の監督のもとで、テバッグ１
２２はオブジェクトコード１２４及びコンパイラデバッ
グ情報１２６が入っている実行可能ファイル１３２を受
取り、デバッグ情報１２６を使用してソースコード１０
２をデバッグする。

【０００７】しかし、従来のトランスレータベースのコ
ンパイルシステム１００では、コンパイラ１１４はソー
スコード１０２についての正確で完全なデバッグ情報を
発生することができない。これは、ソースコード１０２
の構造及び内容に関する情報の多くがソースコード１０
２から中間ソースコード１１０に翻訳する際に失われる
からである。

【０００８】それ故、コンパイラ１１４で発生されたコ
ンパイラデバッグ情報１２６では、ソースコード１０２
を効率良く且つ有効にデバッグするのに使用することが
できない。

【０００９】この問題を解決する従来の試みの１つに
「何もしない」という方法があった。この従来の解決法
では、デバッグ１２２がコンパイラ１１４により発生さ
れたコンパイラデバッグ情報１２４を読取り、本来の変
数名や関数名を復元しようとしたり、発見的方法を使用
してソースコード中の元来のデータ構造などを大まかに
再現しようとしたりする。

【００１０】しかし、この従来の方法では、デバッガ１
２２が元来のソースコード１０２を表示することができ
たとしても、デバッガ１２２の診断出力はどんなに良く
ても不完全で、多くの場合理解できない。また、ほとん
どの場合、ユーザは、変数及び関数を検査するために
は、中間コード中にある「変換された」変数名や関数名
をデバッガ１２２に対して手操作で指定しなければなら
なかった。

【００１１】この問題を解決する従来の他の試みには
「後退法」という方法があった。この従来の解法では、
デバッグ情報１２６を、元来のソースコード１０２の元
来のデータ構造などを再構成するように変換する試みが
なされた。この修正されたデバッグ情報は、次にデバッ
ガ１２２に提示された。

【００１２】しかし、この従来の方法では、修正された
デバッグ情報は、中間ソースコード１１０からソースコ
ード１０２を再構成することが必らずしも可能ではない
ため、不完全で恐らくは不正でさえある。

【００１３】

【発明の目的】本発明は、トランスレータベースのソフ
トウェアコンパイルシステムで意味のあるシンボリック
デバッグ情報を発生することを目的とする。

【００１４】

【発明の概要】本発明の一実施例においては、図２及び
図３に図示するように、また以下に詳細に説明するよう
に、従来の解法に固有の問題点を、コンパイラ１１４及
び修正されたトランスレータ３０２に各々がそれぞれデ
バック情報１２６及び３０６を適宜発生させることによ
り解決している。デバッグ情報１２６及び３０６はマー
ジャ３１２を革新的に使用して組合わされる。得られる
ところの最終デバッグ情報を含むオブジェクトコード３
１６には完全且つ正確なデバッグ情報が入っている。オ
ブジェクトコード３１６に入っている最終デバッグ情報
は、元来のソースコード１０２を完全且つ正確に記述す
る。

【００１５】オブジェクトコード３１６にこの最終デバ
ッグ情報が入り、リンカ１２８により作製される実行可
能ファイル３５０に導入されることにより、修正された
デバッガ３２０は元来のソースコード１０２を完全且つ
正確に表示することができ、変数及び関数を用いて作業
するとき（元のソースコード１０２中の）実際の変数名
及び関数名を効率良く且つ効果的に使用することができ
る。また、このデバッグ情報があるため、デバッガ３２
０は、オーバーロード機能、インヘリタンス及びカプセ
ル化のような概念を取扱うことができる。

【００１６】

【実施例】本発明のこれらの及び他の利点及び特徴、更
には本発明がそれらを如何にして実現しているかは、種
々な実施例に関する以下の詳細な説明及び特許請求の範
囲から解るだろう。

【００１７】まず、以下の実施例の説明の目次を示す。 １．０． 概観 ２．０． トランスレータ ３．０． マージャ ３．１． 入力オブジェクトファイルのインターフェー
ス ３．１．１． 中核オブジェクトファイルクラス ３．１．２． 特殊化クラス ３．２． デバッグ情報マニピュレータ ３．２．１． ステップ８０２−ルックアップテーブル
を構成 ３．２．２． ステップ８０６−ルックアップテーブル
に合せる ３．２．３． ステップ８１０−固定 ３．２．４． ステップ８１４−整頓する ３．３． 出力オブジェクトファイルのインターフェー
ス ４．０． デバッガ

【００１８】１．０． 概観 図３は、本発明２２８のトランスレータベースのコンパ
イルシステムの構造図／機能フローチャートを示す。図
３で、長方形はソフトウェアモジュール／プロセスを表
わし、長円形はソフトウェアモジュール／プロセスの入
力及び出力を表わしている。

【００１９】図３に示すように、本発明の一実施例２２
８は、従来の解法に固有の問題点を、コンパイラ１１４
及び修正されたトランスレータ３０２に、各々がそれぞ
れコンパイラデバッグ情報１２６及びトランスレータデ
バッグ情報３０６を適宜発生させることにより解決して
いる。コンパイラデバッグ情報１２６及びトランスレー
タデバッグ３０６は、マージャ３１２を革新的に使用し
て組合わされる。得られるオブジェクトコード３１６に
は完全且つ正確な最終デバッグ情報が入っている。この
デバッグ情報は元来のソースコード１０２を完全且つ正
確に記述している。

【００２０】下に詳細に説明する通り、オブジェクトコ
ード３１６中に最終デバッグ情報が入っていることによ
り、修正されたデバッガ３２０は元来のソースコード１
０２を表示することができ、変数及び関数を用いて作業
するとき（元来のソースコード１０２中の）実際の変数
名及び関数名を使用することができる。また、この最終
デバッグ情報があるため、デバッガ３２０は、オーバー
ロード機能、インヘリタンス及びカプセル化のような概
念を取扱うことができる。

【００２１】図２に示すように、本発明のトランスレー
タベースのコンパイルシステムは、コンピュータプラッ
トフォーム２０２で動作するアプリケーションコンピュ
ータプログラム２２８である。コンピュータプラットフ
ォーム２０２は、中央処理装置（ＣＰＵ）２１２、ラン
ダムアクセスメモリ（ＲＡＭ）２１０及び入出力インタ
ーフェース２１４を含むハードウェアユニット２０８を
有している。コンピュータプラットフォーム２０２はオ
ペレーティングシステムを含んでおり、マイクロ命令コ
ード２０６を含んでいる場合もある。端末２１８、デー
タストレージ２２２及びプリンタ２２６のような種々の
周辺構成要素をコンピュータプラットフォーム２０２に
接続することができる。

【００２２】本発明の好適実施例では、コンピュータプ
ラットフォーム２０２は、ＨＰ９０００シリーズ３０
０、６００、または８００コンピュータプラットフォー
ムであり、ここで走っているオペレーティングシステム
２０４は、ＨＰ−ＵＸバージョン７．０である。また、
本発明の一実施例にかかるトランスレータベースのコン
パイルシステム２２８は好適にはＣ＋＋言語で書かれて
いる。

【００２３】ＨＰ９０００シリーズの６００及び８００
コンピュータプラットフォームは、実質上同じである。
それ故、ここでＨＰ９０００シリーズ８００コンピュー
タプラットフォームというときはＨＰ９０００シリーズ
の６００及び８００の２つのコンピュータプラットフォ
ームを指すことを理解しなければならない。

【００２４】図３に示すように、本発明の一実施例のト
ランスレータベースのコンパイルシステム２２８は、修
正されたトランスレータ３０２、コンパイラ１１４、革
新的なマージャ３１２、リンカ１２８及び修正されたデ
バッガ３２０を含んでいる。

【００２５】本発明２２８の動作を図３を参照して全般
的に説明する。

【００２６】トランスレータ３０２は、入力としてソー
スコード１０２を受取る。ソースコードは、Ｃ＋＋のよ
うな高レベルのプログラム言語で書くことができる。ト
ランスレータ３０２は、ソースコード１０２の中間変形
体を発生する。ソースコード１０２の中間変形体は中間
ソースコード１１０と呼ばれ、Ｃのようなコンピュータ
プログラム言語で書かれていてよい。

【００２７】トランスレータ３０２はトランスレータデ
バッグ情報３０６も発生する。コンパイラデバッグ情報
１１８（以下に説明する）とは異なり、トランスレータ
デバッグ情報３０６はソースコードの構造及び内容を正
確に反映している。しかし、トランスレータデバッグ情
報３０６は、トランスレータ３０２がメモリの割当やコ
ード生成のような機械特有の事項に関するコンパイラの
判断の知識を持合せていないので、不完全である。

【００２８】コンパイラ１１４は、中間ソースコード１
１０を受取り、ソースコード１０２に対するオブジェク
トコード１２４を発生する。コンパイラ１１４はコンパ
イラデバッグ情報１２６も発生する。オブジェクトコー
ド１２４及びデバッグ情報１２６は、オブジェクトコー
ドファイル１１８に格納される。

【００２９】トランスレータ３０２と異なり、コンパイ
ラ１１４はメモリの割当やコードの生成のような機械特
有の事項に関するコンパイラの判断の知識を持ってい
る。それ故、コンパイラデバッグ情報１２６は、この点
では欠けていない。しかし、上に述べたように、コンパ
イラデバッグ情報１２６はなお、ソースコード１０２の
構造及び内容を完全且つ正確に表わしていない。

【００３０】マージャ３１２は、オブジェクトコードフ
ァイル１１８とトランスレータデバッグ情報３０６を受
け取る。上述の通り、コンパイラデバッグ情報１２６及
びトランスレータデバッグ情報３０６はそれぞれある領
域を欠いている。しかし、これらの領域は重なっていな
い。それ故、マージ３１２はコンパイラデバッグ情報１
２６及びトランスレータデバッグ情報３０６に入ってい
る情報を組合せて最終デバッグ情報を作製する。マージ
ャ３１２は、最終デバッグ情報をコンパイラ１１４が発
生したオブジェクトコード１１８と組合せて、最終デバ
ッグ情報を含むオブジェクトコード３１６を作製する。

【００３１】最終デバッグ情報は元来のソースコード１
０２を完全且つ正確に表わしている。

【００３２】リンカ１２８は、最終デバッグ情報を含む
オブジェクトコード３１６を他のオブジェクトコードフ
ァイル１３４とリンクする。リンカ１２８は、最終デバ
ッグ情報が入っている実行可能ファイル３５０を作製す
る。

【００３３】デバッガ３２０は、最終デバッグ情報が入
っている実行可能ファイル３５０を入力として受取る。
ユーザ（図３には示してない）の監督のもとに、デバッ
ガ３２０は最終デバッグ情報を使用して元来のソースコ
ード１０２を表示し、変数及び関数を用いて作業すると
きは（元来のソースコード１０２中の）実際の変数名及
び関数名を使用する。また、デバッガ３２０は、最終デ
バッグ情報を使用してオーバーロード機能、インヘリタ
ンス及びカプセル化のような概念を取扱う。

【００３４】本発明の一実施例のシステム２２８のデバ
ッガ３２０は、それが最終デバッグ情報中に埋め込まれ
たトランスレータデバッグ情報を利用するという特徴を
備えているという点で従来のデバッガ１２２の修正され
たものである。

【００３５】本発明の好適実施例では、ソースコード１
０２はＣ＋＋言語で書かれており、中間ソースコード１
１０はＣ言語で書かれている。

【００３６】しかし、本発明は、どんなトランスレータ
ベース環境でも働くようにされており、またそのように
意図されている。従って、本発明の範囲は、Ｃ＋＋／Ｃ
言語に限定されない。

【００３７】Ｃ＋＋言語は当業者には周知の事項である
が、その一般的説明が必要ならば、Margaret Ellis及び
Bjarne Stroustrup 著「Annotated C++ Reference Manu
al （注訳付きＣ＋＋便覧）」（Addison Wesley 1990）
を参照されたい。Ｃ言語も周知な事項であるが、一般的
説明が必要ならば、American National Standard for I
nformation Systems-Programming Language Ｃ（情報シ
ステムに関するアメリカ国家規格−プログラム言語Ｃ）
（文書番号X3J11/90-013）を参照されたい。

【００３８】次の各章では本発明２２８のトランスレー
タベースのコンパイルシステムのシステムについて一層
詳細に説明する。

【００３９】コンパイラ１１４のような、本発明２２８
の或る局面は、既存のコンパイラ、トランスレータ、リ
ンカ及びデバッガの技術を用いて実現することができ
る。しかし、既存のトランスレータ及びデバッガの技術
に修正を加えることは、本発明の改善を達成するのに必
要である。以下の各章での説明は、既存のトランスレー
タ及びデバッガの技術（及び革新的なマージャ３１２）
に加えられるこれら修正に重点を置く。既存のコンパイ
ラ、リンカ、トランスレータ及びデバッガの技術も当業
者には周知名者であるが、その一般的説明については、
Alfred V.Aho、Ravi Sethi及びJeffrey D.Ullman著「Co
mpilers, Princioles, Techniques, and Tools（コンパ
イラ、原理、手法及びツール）」（Addison Wesley 198
6）を参照されたい。

【００４０】２．０ トランスレータ 図４は、本発明２２８のトランスレータ３０２の構造図
／フローチャートを示す。図４で、長方形はソフトウェ
アモジュール／プロセスを表わし、長円形はソフトウェ
アモジュール／プロセスの入力及び出力を表わす。

【００４１】図４に示す通り、本発明のシステム２２８
のトランスレータ３０２は、スキャナ／パーザ４０２、
デバッグ情報生成部４１０及びコード生成部４１８を含
んでいる。

【００４２】スキャナ／パーザ４０２は、Ｃ＋＋のよう
な高レベルプログラム言語で書くことができるソースコ
ード１０２を受取り、ソースコード１０２を表わす意味
情報を含む内部データ構造（意味情報／内部データ構造
４０６）を構築する。デバッグ情報生成部４１０は、意
味情報含む内部データ構造、つまり意味情報／内部デー
タ構造４０６を受取り、トランスレータデバッグ情報３
０６を生成する。

【００４３】コード生成部４１８はまた意味情報／内部
データ構造４０６を受取って中間ソースコード１１０を
発生する。中間ソースコード１１０はＣ言語で書かれて
いてよい。

【００４４】トランスレータ３０２に含まれているデバ
ッグ情報生成部４１０は、コンパイラ１１４に含まれて
いるデバッグ情報生成部（図示せず）と非常に良く似た
動作をする。従って、デバッグ情報生成部４１０の構造
及び動作の一般的説明は、上に引用したAlfred V.Aho、
Ravi Sethi及びJeffery D.Ullman著「Compilers, Princ
iples, Techniques, and Tools」に書いてある。

【００４５】トランスレータ３０２に含まれているデバ
ッグ情報生成部４１０とコンパイラ１１４に含まれてい
るデバッグ情報生成部の主な相違は、デバッグ情報生成
部４１０はトランスレータ３０２に含まれているので、
ソースコード１０２の構造及び内容を知っているという
ことである。それ故、デバッグ情報生成部４１０により
発生されるトランスレータデバッグ情報３０６は、ソー
スコード１０２の構造及び内容を正確且つ完全に反映し
ている。

【００４６】しかし、トランスレータ３０２に含まれて
いるデバッグ情報生成部４１０は、マシンアーキテクチ
ャ及びマシンアドレス（関数及び変数のアドレスを含
む）を取扱う情報を知っていない。それ故、デバッグ情
報生成部４１０により発生されるトランスレータデバッ
グ情報３０６は、マシンアーキテクチャ及びマシンアド
レスの情報を欠いている。トランスレータデバッグ情報
３０６に欠けている特定の局面について下に詳細に説明
する。

【００４７】３．０ マージャ マージャ３１２は、トランスレータ３０２が作製したシ
ンボリックデバッグ情報３０６をコンパイラ１１４が作
製したコンパイラデバッグ情報１２６（及びオブジェク
トコード１２４）と組合せる。

【００４８】図５は、マージャ３１２の構造図／機能フ
ローチャートを示す。図５で、長方形はソフトウェアモ
ジュール／プロセスを表わし、長円形はソフトウェアモ
ジュール／プロセスの入力及び出力を表わしている。

【００４９】図５に示す通り、マージャ３１２は、入力
オブジェクトファイルインターフェース５０２、５０
４、デバッグ情報マニピュレータ５１０及び出力オブジ
ェクトファイルインターフェース５１４を含んでいる。
一般に、入力オブジェクトファイルインターフェース５
０２は、オブジェクトコードファイル１１８から読出し
を行ってコンパイラデバッグデータ構造５１６を生成す
る。入力オブジェクトファイルインターフェース５０４
は、トランスレータデバッグ情報３０６から読出しを行
ってトランスレータデバッグデータ構造５１８を生成す
る。デバッグ情報マニピュレータ５１０は、デバッグデ
ータ構造５１６、５１８に入っている情報を組合せてマ
ージ済みルックアップテーブル５２８及びポータブル出
力決定用情報（portable input fixup）５３０を出力す
る。出力オブジェクトファイルインターフェース５１４
は最終デバッグ情報を含むオブジェクトコード３１６に
対する書込みを行う。

【００５０】マージャ３１２の機能フローチャートを図
６に示す。マージャ３１２の動作を図５及び図６を参照
して下に説明する。

【００５１】ステップ６０２と６０６で、入力オブジェ
クトファイルインターフェース５０２、５０４はオブジ
ェクトコードファイル１１８とトランスレータデバッグ
情報ファイル３０６をオープンし、デバッグ情報をこれ
らのファイル１１８、３０６から読出す。入力オブジェ
クトファイルインターフェース５０２、５０４は、デバ
ッグ情報をデバッグデータ構造５１６、５１８に置く。
ここに置かれた情報はデバッグ情報マニピュレータ５１
０に渡される。

【００５２】ステップ６１０で、デバッグ情報マニピュ
レータ５１０は、コンパイラデバッグデータ構造５１６
とトランスレータデバッグデータ構造５１８を比較し、
レコードをコンパイラデバッグデータ構造５１６からト
ランスレータデバッグデータ構造５１８の対応するレコ
ードにコピーする。更新されたトランスレータデバッグ
データ構造はマージ済みルックアップテーブル５２８に
格納される。

【００５３】ステップ６１４で、出力オブジェクトファ
イルインターフェース５１４は、オブジェクトコード１
２４及びマージ済みルックアップテーブル５２８からの
情報を新たな最終デバッグ情報を含むオブジェクトコー
ド３１６にコピーする。

【００５４】入力オブジェクトファイルインターフェー
ス５０２、５０４、デバッグ情報マニピュレータ５１０
及び出力オブジェクトファイルインターフェース５１４
について次の章で一層詳細に説明する。

【００５５】３．１ 入力オブジェクトファイルインタ
ーフェース図５に示すように、入力オブジェクトファイ
ルインターフェース５０２及び５０４は、入力としてそ
れぞれオブジェクトコードファイル１１８及びトランス
レータデバッグ情報３０６を受取る。

【００５６】オブジェクトコードファイル１１８のコン
パイラデバッグ情報１２６は、コンパイラからのデバッ
グ用名前及び型テーブル（すなわち、グローバルな名前
及び型テーブル（Global Name and Type Talbe、ＧＮＴ
Ｔ）及びローカルな名前及び型テーブル（Local Name a
nd Type Table、ＬＮＴＴ）等の各種情報を含んでい
る。コンパイラデバッグ情報１２６は、コンパイラから
の値テーブル（ＶＴ）も含んでいるが、これは実質的に
は名前ストリングのテーブルである。コンパイラデバッ
グ情報１２６はまた、コンパイラ１１４のオブジェクト
コード１２４のソース行テーブル（ＳＬＴ）を含んでい
る。コンパイラデバッグ情報１２６はまた決定用情報リ
スト（fixup list）を含んでいるが、これはリンカ１２
８がコンパイラ１１４のオブジェクトコード１２４を決
定、設定するのに必要とする情報を含んでいる。オブジ
ェクトファイル１１８は、オブジェクトファイルシンボ
ルテーブルを含んでいる。このシンボルテーブルは各種
識別子（すなわち、シンボル）の名前及びアドレスを含
んでいる。これらのシンボルは決定用情報リスト中で参
照される。

【００５７】コンパイラデバッグ情報１２４と同様、ト
ランスレータデバッグ情報３０６は、トランスレータか
らのデバッグ用名前及び型テーブルとトランスレータか
らの値テーブル（ＴＶ）を含んでいる。トランスレータ
デバッグ情報３０６はソース行テーブル（ＳＬＴ）や決
定用情報リストを含んでいない。それは、トランスレー
タ３０２がそのような情報を発生しないからである。

【００５８】入力オブジェクトファイルインターフェー
ス５０２は、コンパイラデバッグ情報１２６を読出し、
それをコンパイラデバッグデータ構造５１６に置く。同
様に、入力オブジェクトファイルインターフェース５０
４は、トランスレータデバッグ情報３０６を読出してそ
れをトランスレータデバッグデータ構造５１８に置く。
図５に示すように、コンパイラ及びトランスレータデバ
ッグデータ構造５１６、５１８はデバッグ情報マニピュ
レータ５１０への入力である。

【００５９】コンパイラデバッグデータ構造５１６とト
ランスレータデバッグデータ構造５１８は同じフォーマ
ットを共有している。この共通のフォーマットを表１に
示す。

【００６０】 〈表−１〉 struct debuginfo { char *header; // 各種デバッグ情報要素 int header_len; char *gntt; int gntt_len; char *lntt; int lntt_len; char *slt; int slt_len; char *vt; int vt_len; dtab *gtbl; // 早見参照中間テーブル dtab *ltble; oldfixuplist *oldgfxup; // 古い決定情報リスト (gnt
t, lntt) oldfixuplist *oldlfxup; newfixuplist *gfxup; // 新しい決定情報リスト (gnt
t, lntt) newfixuplist *lfxup; };

【００６１】入力オブジェクトファイルインターフェー
ス５０２及び入力オブジェクトファイルインターフェー
ス５０４は、本質的に同じ様に動作する。しかし、多少
の些細な相違がある。このような相違はその入力が相違
していることを反映している。例えば、入力オブジェク
トファイルインターフェース５０２は、オブジェクトコ
ード１２４中の名前がソースコード１０２中の名前と一
致するように名前を復元するソフトウェアルーチンを含
んでいる。

【００６２】本発明２２８の好適実施例では、入力オブ
ジェクトファイルインターフェース５０２、５０４（及
び出力オブジェクトファイルインターフェース５１４
も）は、クラスとして実現されている。これらクラスの
インスタンスはオブジェクトコード及びデバッグ情報が
入っているファイルを読み書きするのに使用される。

【００６３】これらのクラスは２つの層に分けられる。
これらの層とは、基底クラス（BaseClass）を表わす中
核オブジェクトファイルクラス（Core Object File Cla
sses）と、中核オブジェクトファイル基底クラスから誘
導されたクラスを表わす特殊化クラス(Specialized Cla
sses）である。これらクラスについて次の章で説明す
る。

【００６４】３．１．１ 中核オブジェクトファイルク
ラス 中核オブジェクトファイルクラスは、オブジェクトファ
イルヘッダやシンボルテーブルのような共通なオブジェ
クトファイルデータ構造を読出すのに使用される。中核
オブジェクトファイルクラスは、シンボルテーブル内の
シンボルを参照するアクセスルーチン及び初期設定ポイ
ンタを参照するアクセスルーチンを含む。中核オブジェ
クトファイルクラスはオブジェクトファイルを読み書き
するジェネリックルーチンもある。

【００６５】本発明の好適実施例２２８では、２つの中
核オブジェクトファイルクラス、som300とsom800、があ
る。som300はＨＰ９０００シリーズ３００コンピュータ
プラットフォーム202 で動作し、som800はＨＰ９０００
シリーズの６００及び８００コンピュータプラットフォ
ーム２０２で動作する。som300及びsom800について次章
で説明する。

【００６６】３．１．１．１ クラスsom300クラスsom30
0という抽象概念の主な目的は、オブジェクト／デバッ
グファイル１１８、３０６、３１６に対する効率的且つ
ユーザから分かりやすいインターフェースを提供するこ
とである。クラスsom300を構成するコンピュータプログ
ラムセグメントを表２に示す。

【００６７】 〈表−２〉 class coffheader : public exec { public: coffheader() {} coffheader(fstream&); coffheader(coffheader& other) {*this = other;} int validate(); }; class syment300 : public nlist_ { public: syment300() {name = NULL;}; ■syment300(); char *name; int copy(char *ptr); int symsiz() {return ( sizeof(long) + 2 * sizeof(char) + 2 * sizeof(short) + n_length);} syment300& operator = (syment300& other); friend int digest(char *, long, syment300 *&); }; class som300 { protected: char open; // このsomはオープンしているか？ char valid; // このsomは正しいか？ coffheader *header_ptr; // オブジェクトファイルヘッダへの // ポインタ syment300 *sym; // シンボルテーブルへのポインタ int sym_count; // シンボル数 long start_of_data; // オブジェクトファイル中での // 初期化されたデータのオフセット fstream *somfile; // 入出力のためにオープンしている // ファイルのポインタ public: // コンストラクタ及びデストラクタ som300(); som300(char *filename, int mode=iso::in); // ファイル名で初期化 ■som300(); // 手短に正当性をチェックするルーチン operator int() {return valid;} // パッケージされた入出力アクセスルーチン // これらのルーチンはfstream中の対応するルーチンと // 同じ機能を果す streampos tellg () { return somfile->tellg(); } istream& seekg (streamoff so, seek_dir ds); { return somfile->seekg(so, sd); } istream& read (char *s, long n) { return somfile->read(s, (int) n); } streampos tellp () { return somfile->tellp(); } ostream& seekp (streamoff so, seek_dir sd) { return somfile->seekp(so, sd); } ostream& write (char *s, long n) { return somfile->write(s, (int) n); } // シンボルテーブルアクセスルーチン int num_symbols() {return sym_count;} syment300 *get_symbols() {return sym;} syment300 *find_symbol(char *); char *sym_name (syment300& s); { return s.name; } long sym_loc (syment300& s); // ファイル中でsymが // 指している位置 long sym_val (syment300& s); // ロードされたプログ // ラム中でsymが // 指している位置

【００６８】sym_loc()関数は、オブジェクト／デバッ
グファイル１１８、３０６中でシンボルの初期設定値を
格納しているロケーションを返す。sym_loc()関数は初
期設定ポインタにパッチを当てるのに使用される。

【００６９】sym_val()関数は、コンピュータプログラ
ムをＲＡＭ２１０にロードされた時のシンボルの実行時
アドレスを返す。

【００７０】coffheaderクラスは、コンストラクタ及び
検査子関数を付加するために、ヘッダを包むのに主に使
用される。

【００７１】cyment300クラスは重要である。ＨＰ９０
００シリーズ３００コンピュータプラットフォーム２０
２で作られたオブジェクトコードファイル１１８の中の
シンボルの通常の表現は、クランチ（crunch）されたレ
コード（struct nlist_）の後ろに、当該シンボル名を
ナルコードで終端しないときの正確なバイト長を示す数
が付けられたものである。

【００７２】従って、その最初の動作として、コンスト
ラクタsom300()は、シンボルテーブル全体を読取り、シ
ンボルテーブルをもっと使いやすい形に、具体的にはsy
ment300レコードの配列に変換する。syment300の配列に
は２つの長所がある。 １．大きさが一定のレコードの配列であるから、走査
（traverse）し易い。 ２．名前は今やナルコードで終端され且つその先頭部分
への直接のポインタを含んでいるので取扱い易い。

【００７３】クラスsyment300のcopy()関数は、加工前
のシンボルテーブルからsyment300ノードを作り出すた
めに、digest()関数により使用される。演算子「＝」は
このようなノードのコピーを容易にする。

【００７４】３．１．１．２ クラスsom800 クラスsom800はクラスsom300より幾らか複雑である（Ｈ
Ｐ９０００シリーズ６００及び８００のオブジェクトフ
ァイルのフォーマットが複雑であるため）。しかし、ク
ラスsom800はクラスsom300と実質上同じ機能を果す。

【００７５】クラスsom800を構成するコンピュータプロ
グラムセグメントを表３に示す。クラスsom800に含まれ
ているクラス、データ構造及び機能はクラスsom300にあ
るものと相似である。

【００７６】 〈表−３〉 class somheader : public header { public: somheader() {} somheader(fstream&); somheader(somheader& other) {*this = other;} int validate(); }; class som800 { protected: char open; // このsomはオープンしているか？ char valid; // このsomは正しいか？ somheader *header_ptr; // オブジェクトファイルヘッダへの // ポインタ SPAHDR *space_dict; // スペーステーブルへのポインタ int space_count; // スペースの数 SCNHDR *subspace_dict; // サブスペーステーブルへのポインタ int subspace_count; // サブスペースの数 char *space_strings; // スペース文字列テーブルへのポインタ int space_strings_size; // その長さ SYMENT *sym; // シンボルテーブルへのポインタ int sym_count; // シンボルの数 char *symbol_strings; // シンボル文字列テーブルへのポインタ int symbol_strings_size; // その長さ INITPTR init_ptrs; // 初期化ポインタへのポインタ int init_ptrs_count; // 初期化ポインタの数 fstream *somfile; // オープンしているファイルのポインタ public: // コンストラクタ及びデストラクタ som800(); som800(char *filename, int mode=ios::in); // ファイル名で初期化 ■som800(); // 手短な正当性チェッカ operator int() {return valid;} // パッケージされた入出力アクセスルーチン // これらのルーチンはfstream中の対応するルーチンと同じ機能を果す streampos tellg () { return somfile->tellg(); } istream& seekg (streamoff so, seek_dir sd) { return somfile->seekg(so, sd); } istream& read (char *s, long n) { return somfile->read(s, (int) n); } streampos tellp () { return somfile->tellp(); } ostream& seekp (streamoff so, seek_dir sd) { return somfile->seekp(so, sd); } ostream& write (char *s, long n) { return somfile->write(s, (int) n); } // シンボルテーブルアクセスルーチン int num_spaces() {return space_count;} int num_subspaces() {return subspace_count;} int num_symbols() {return sym_count;} int num_init_ptrs() {return init_ptrs_count;} unsigned int dp() {return header_ptr->presumed_dp;} SPAHDR *get_space_dict() {return space_dict;} SCNHDR *get_subspace_dict() {return subspace_dict;} SYMENT *get_symbols() {return sym;} INITPTR *get_init_ptrs() {return init_ptrs;} SPAHDR *find_space(char *); char *space_name(SPAHDR& s); { return &space_strings[s.STR_INDEX]; } SCNHDR *find_subspace(SPAHDR *, char *); char *subspace_name (SCNHDR& s) { return &space_strings[s.STR_INDEX]; } SYMENT *find_symbol(char *, SCNHDR *subsp = NULL, int typ = -1); char *sym_name 8SYMENT& s) { return &symbol_strings[s.offset]; } long sym_loc (SYMENT& s); // ファイル中でsymが指す位置 long sym_val (SYMENT& s); // ファイル中でロードされた // プログラムが指す位置 };

【００７７】３．１．２ 特殊化クラス 特殊化クラスは、コンパイラ及びトランスレータデバッ
グ情報１２６、３０６に対する読み書を行うルーチンを
含む。特殊化クラスは、オブジェクト／デバッグファイ
ル１１８、３０６を他のオブジェクト／デバッグファイ
ル（代替デバッグテーブルが入っている）にコピーし、
シンボルをオブジェクト／デバッグファイル１１８、３
０６に入っているシンボルテーブルに追加するルーチン
も含んでいる。

【００７８】本発明の好適実施例２２８では、debugsom
300及びdebugsom800という２つの特殊化クラスがある。
debugsom300はＨＰ９０００シリーズ３００コンピュー
タプラットフォーム２０２で動作し、debugsom800はＨ
Ｐ９０００シリーズ６００及び８００コンピュータプラ
ットフォーム２０２で動作する。debugsom300及びdebug
som800について次の章で説明する。

【００７９】３．１．２．１ クラスdebugsom300 クラスdebugsom300を構成するコンピュータプログラム
セグメントを表４に示す。

【００８０】 〈表−４〉 class debugsom300 : public som300 { protected: long last_written_pos; // 最後の書込位置を憶えておく public: // コンストラクタ debugsom300(); debugsom300(char *filename, int mode=ios::in); // ファイル名で // 初期化する // デストラクタはない // （seekpのために）最後の書込位置を返す int endpos() {return last_written_pos;} // デバッグ情報を読み書きする debuginfo *read_debug_info(); int write_debug_info(debuginfo *new_dbg_info); // シンボルテーブルにシンボルを付加する syment300 *add_symbol(char *nm, int sym_typ, int dreloc = 0); // 力仕事ルーチン：oldsomを*thisに複写して、 // デバッグ情報をcpp_infoで置き換える int copy(debugsom300& oldsom, debuginfo *cpp_info); };

【００８１】ルーチンdebugsom300()はオブジェクト／
デバッグファイル１１８、３０６をオープンし、その内
容の一部を読出す。ルーチンread_debug_info()はファ
イル１１８、３０６にアクセスしてその内容の残りを読
出す。

【００８２】ルーチンread_debug_info()はまた情報を
デバッグデータ構造（表１に示す）に書き込む。

【００８３】３．１．２．２ クラスdebugsom800 クラスdebugsom800を構成するコンピュータプログラム
セグメントを表５に示す。クラスdebugsom800に含まれ
ているクラス、データ構造及び機能は、debugsom300ク
ラス中のものと相似である。

【００８４】 〈表−５〉 class debugsom800 : public som800 { protected: int last_written_pos; // 最後の書込位置 // 手入れ情報を書き出すためのルーチン int copy_old_fixups(debugsom800& newsom); int add_new_fixups(void); public: // コンストラクタ debugsom800(); debugsom800(char *filename, int mode=ios::in); // ファイル名で // 初期化する // デストラクタはない // （seekpのために）最後の書込位置を返す int endpos() {return last_written_pos;} // デバッグ情報を読み書きする debuginfo *read_debug_info(); int write_debug_info(debuginfo *new_dbg_info); // シンボルテーブルにシンボルを付加する syment800 *add_symbol(char *nm, int sym_typ, int sym_scope, int subsp); // 力仕事ルーチン：oldsomを*thisに複写して、 // デバッグ情報をcpp_infoで置き換える int copy(debugsom800& oldsom, debuginfo *cpp_info); // 古い手入れ情報を読む friend oldfixuplist *read_debug_fixups(debugsom800&, int, char *); };

【００８５】３．２ デバッグ情報マニピュレータ 図７は、デバッグ情報マニピュレータ５１０の構造図／
機能フローチャートを示す。図７で、長方形は、ソフト
ウェアモジュール／プロセスを表わし、長円形は、ソフ
トウェアモジュール／プロセスの入力及び出力を表わ
す。

【００８６】図７に示す通り、デバッグ情報マニピュレ
ータは、ルックアップテーブル構築部７１０、７１２、
ルックアップテーブル整合部（lookup table matcher）
７２６及びルックアップテーブル調整部（lookup table
fixer）７４４を含んでいる。

【００８７】図８は、デバッグ情報マニピュレータ５１
０のフローチャートを示す（図８のフローチャートは、
図６のステップ６１０の動作をもっと詳細に見たもので
ある）。デバッグ情報マニピュレータ５１０の動作を、
今度は図５、図７及び図８を参照して説明する。

【００８８】ステップ８０２で、ルックアップテーブル
構築部７１０及び７１２は、コンパイラデバッグデータ
構造５１６及びトランスレータデバッグデータ構造５１
８を受取って、コンパイラルックアップテーブル７１８
及びトランスレータルックアップテーブル７２０を作
る。ルックアップテーブル７１８及び７２０は、ルック
アップテーブル７１８、７２０がDNTTの正確なブロック
構造を反映し、各入れ子ブロックテーブルが意味のある
DNTTのエントリ全てについてのエントリを含んでいると
いう点で、それぞれコンパイラデバッグデータ構造５１
６及びトランスレータデバッグデータ構造５１８中に含
まれているDNTTを抽象化したものである。

【００８９】ステップ８０６で、ルックアップテーブル
整合部７２６は、ルックアップテーブル７１８、７２０
を整合（match）させて整合済みコンパイラルックアッ
プテーブル（matched compiler lookup table）７３２
及び整合済みトランスレータルックアップテーブル（ma
tched translator lookup table）７３４をそれぞれ作
製する。ステップ８０６が終了すると、整合済みコンパ
イラルックアップテーブル７３２のエントリは整合済み
トランスレータルックアップテーブル７３４のエントリ
と整合している、つまり対応するようになっている。

【００９０】ステップ８１０で、ルックアップテーブル
調整部７４４が整合ルックアップテーブル７３２、７３
４を調整する。この調整過程中、ルックアップテーブル
調整部は、情報を整合済みコンパイラルックアップテー
ブル７３２から整合済みトランスレータルックアップテ
ーブル７３４にコピーする。

【００９１】具体的には、ルックアップテーブル調整部
７４４は、整合ルックアップテーブル７３２、７３４を
走査して全ての可能且つ必要な情報を整合済みコンパイ
ラルックアップテーブル７３２のエントリからその対応
する整合済みトランスレータルックアップテーブル７３
４のエントリにコピーする。調整する必要のあるフィー
ルドについて、ルックアップテーブル調整部７４４は、
出力オブジェクトファイルインターフェース５１４につ
いての「新しい決定用情報」ノードを作り出す。

【００９２】整合済みコンパイラルックアップテーブル
７３２から整合済みトランスレータルックアップテーブ
ルにコピーされる情報には、デバッグ用名前及び型テー
ブル（ＤＮＴＴ）、ソース行テーブル（ＳＬＴ）及びポ
ータブル決定用情報リストがある。（上に説明したよう
に、この情報はルックアップテーブル７１８、７２０に
入っている。）

【００９３】具体的には、整合済みトランスレータルッ
クアップテーブルに入っているDNTTの各種のエントリの
値は、整合済みコンパイラルックアップテーブル７３２
からの情報を用いて修正されなければならない。このよ
うなDNTTエントリにはSVARエントリがあるが、そのロケ
ーション及びオフセット値は整合済みコンパイラルック
アップテーブル７３２からの情報を用いて修正されなけ
ればならない。他のこのようなDNTTエントリにはDVAR及
びFPARAMのエントリがあり、これらのロケーション及び
レジスタパラメータ値は整合済みコンパイラルックアッ
プテーブル７３２からの情報を用いて修正されなければ
ならない。

【００９４】他のそのようなDNTTエントリにはFUNCエン
トリがあり、そのentryaddr、lowaddr、hiaddr、addr及
び最適化値は、整合済みコンパイラルックアップテーブ
ル７３２からの情報を用いて修正されなければならな
い。

【００９５】他のそのようなDNTTエントリには、BEGI
N、END、CLASS_SCOPE、WITH、LABEL及びOBJECT_IDの各
エントリがあり、それらのアドレス値は整合済みコンパ
イラルックアップテーブル７３２からの情報を用いて修
正されなければならない。

【００９６】また、ルックアップテーブル調整部７４４
は、整合済みコンパイラルックアップテーブル７３２に
入っているSLTを使用して整合済みトランスレータルッ
クアップテーブル７３４のためのSLTを作り出す。SLT
は、ステートメント及びブロックの始めと終りのロケー
ションを示す情報を含んでいる。

【００９７】整合済みトランスレータルックアップテー
ブル７３４のためのSLTを作り出しながら、ルックアッ
プテーブル調整部７４４は、BEGIN及びENDのような、ス
コープに関係するSLTエントリをそれらの対応するDNTT
エントリと整合させる。従って、ルックアップテーブル
調整部７４４は、ソースコード１０２のブロック構造を
正しく反映するDNTT及びSLTのエントリの整合した組合
せが得られてそれが整合トランスレータルックアップテ
ーブル７３４に格納されるまで、SLTエントリを追加及
び削除し、整合しないDNTTエントリを無効にする。整合
しないSLT及びDNTTエントリには除去用の印を付ける。

【００９８】多くの場合、整合済みトランスレータルッ
クアップテーブル７３４に挿入しなければならない情報
は、リンク時点までわからない。例えば、静的変数のア
ドレス、あるいは関数の開始及び終りについてのコード
アドレスは、リンクするまでわからない。

【００９９】これらの場合には、ルックアップテーブル
調整部７４４は、決定用情報（fixup）を作り出して、
リンカ１２８にリンクプロセス中適切な値をオブジェク
トコード３１６中の最終デバッグ情報に挿入するよう指
示する。

【０１００】決定用情報は、DNTTのSVAR、FUNC及びOBJE
CT_IDの各エントリについて作らなければならない。

【０１０１】ステップ８１４で、ルックアップテーブル
調整部７４４は整頓段階に入り、除去用の印が付いてい
るSLT及びDNTTを削除する（SLTエントリの場合）かまた
は無効にする（DNTTエントリの場合）。

【０１０２】ステップ８１０及び８１４の終了に続い
て、図７に示すように、ルックアップテーブル調整部７
４４は、マージ済みルックアップテーブル５２８を出力
するが、これには整合ルックアップテーブル７３４及び
決定用情報リスト５３０が入っている。

【０１０３】図８のステップ８０２、８０４、８１０及
び８１４について、次章で更に詳細に説明する。

【０１０４】３．２．１ ステップ８０２−ルックアッ
プテーブルを構築するルックアップテーブル構築部７１
０、７１２により発生されたルックアップテーブル７１
８、７２０は、ブロック構造を持つ入れ子になったテー
ブルで、DNTTのエントリを保持するのに使用される。プ
ロック構造は次のDNTT対の形で表わされる。 ・ K_MODULE と K_END ・ K_FUNCTION と K_END ・ K_BEGIN と K_END

【０１０５】このような対は、各々別個のクラスで表わ
されるが、これらクラスは皆dtabと呼ばれる共通基底ク
ラスから誘導される。

【０１０６】例えば、下記のコンピュータプログラムの
抜粋を考える。

【０１０７】int vl; main (int argc, char **argv) { int k = argc; if( k > 1 ) { char* foo = argv[0]; } int j = k / 2; j += 2; if( j > 3 ) { char *foo = argv[1]; } } int v2;

【０１０８】以下の表６は、ルックアップテーブル構築
部７１０，７１２がこのプログラム抜粋をルックアップ
テーブル７１８、７２０中で表わす方法を示している。

【０１０９】 〈表−６〉 TABLE (Start NTT: 0; End NTT: 0; Srcf: 0) MODULE (Name: <<<NULL_SYMBOL>>>; Alias: ; Start NTT: 40008988; End NTT: 40008988; Start SLT: -1; End SLT: -1; Srcf: 0) Src (Name: t1.c; NTT: 400089a0; SLT: -1) Svar (Name: v1; NTT: 40008aa8; Off: 0; disp: 0; loc: 0; sym: 0; Srcf: 0) Svar (Name: v2; NTT: 40008ac0; off: 0; disp: 0; loc: 0; sym: 0; Srcf: 0) FUNCTION (Name: main; Alias: _MAIN_; Start NTT: 400089ac; End NTT: 400089ac; Start SLT -1; End SLT: -1; Srcf: 400097c8) Fparam (Name: argc; NTT: 400089d0; spoff: 0; Srcf: 400097c8) Fparam (Name: argv; NTT: 40008a00; spoff: 0; Srcf: 400097c8) BLOCK (Start NTT: 40008a18; End NTT: 40008a18; Start SLT: -1; End SLT: -1; Srcf: 400097c8) Dvar (Name: j; NTT: 40008a3c; spoff: 0; Srcf: 400097c8) Dvar (Name: k; NTT: 40008a24; spoff: 0; Srcf: 400097c8) BLOCK (Start NTT: 30008a54; End NTT: 40008a54; Start SLT: -1; End SLT: -1; Srcf: 400097c8) Dvar (Name: foo; NTT: 40008a6c; spoff: 0; Srcf: 400097c8) BLOCK (Start NTT: 40008a90; End NTT: 40008a90; Start SLT: -1; End SLT: -1; Srcf: 0) Dvar (Name: foo; NTT: 40008aa8; spoff: 0; Srcf: 0)

【０１１０】表６の中の表現の中で注意しておくべき特
徴がいくつかある。第１に、各「ブロック」は１つのテ
ーブルで表わされている。最も外側のレベル（グローバ
ルレベル）は、テーブルMODULEで表わされている。（実
際には、最も外側レベルは外側のTABLEで表わすべきで
あるが、DNTT_MODULEエントリに対するテーブルを作る
準備を行わなければならない。）「関数」レベルのブロ
ックはテーブルFUNCTIONで表わされる。内部ブロックは
全てテーブルBLOCKで表わされる。

【０１１１】第２に、テーブルノードは幾らかの一般情
報を含んでおり、テーブル型は幾らかの型固有の情報を
持っている。具体的には、ブロックの始めと終りに対応
するDNTTエントリへのポインタは、ブロックの始めの直
前及び終りの直前（表６には示されていない）に見られ
る直前のDNTT_SOURCEFILEへのポインタのように、全て
のテーブルについて格納される。

【０１１２】また、SLT内の対応するブロックの始めと
終りに対するSLTインデクスは、全ての関数、ブロック
及びモジュールについて格納される。また、名前及びエ
イリアスをへのポインタが全ての関数、ブロック及びモ
ジュールについて格納される。

【０１１３】第３に、ブロック内の全てのエントリは、
ハッシングされてそのブロックに対応するテーブルに入
れられている。色々な型のエントリが生成され、その各
々はそのエントリの型に対応する幾らかの特定の情報を
持っている。

【０１１４】最後に、エクスポート及びインポートされ
たグローバル変数（GNTTに対応する）についての他のTA
BLEテーブルが生成される（表６には示されていな
い）。このテーブルはブロック構造を有していない。

【０１１５】本発明の好適実施例では、ブロック構造対
を表わす以下の５つのクラスがある：datab, blocktab,
functab, modtab,及びnulltabである。これらクラスに
ついて次章で詳細に説明する。

【０１１６】３．２．１．１ クラスdtabdtabは、ルッ
クアップテーブル７１８、７２０の機能のほとんどを実
現する基底クラスである。dtabクラスは、エントリのた
めのハッシュテーブル、サブテーブルのリストへのポイ
ンタ、その直接の親テーブルへの逆方向ポインタを含
む。

【０１１７】これに加えて、dtabクラスは、反復の間の
状態を保持するメンバと、ある重要なデバッグ構造への
ポインタを含む。

【０１１８】dtabは抽象基底クラスである（表７中の宣
言ttyp()を参照）。

【０１１９】dtabクラスを構成するクラス、データ構
造、変数及び関数を表７に示す。

【０１２０】 〈表−７〉 class dtab { private: dsyment **ent; // 要素用のハッシュテーブル int numbuckets, numtables; dtablist *firstchild; // テーブルの下位リストへの // ポインタ dtab *parent; // 親テーブルへのポインタ dtablist *nextchild; // 反復子が使用 dnttentry *ntt_start, *ntt_end; // テーブルの付き合わせ及び // 手当をするルーチンが使用 SLTPOINTER slt_start, slt_end; // 同 上 dtab *corresponding; // 同 上 dsrcent *srcf, *esrcf; // ソースファイルテーブル要素への // ポインタ fakeblock *n_fakes; // このブロック内の // 「フェイク（模造）」ブロック protected: int make_table(int buckets); // コンストラクタから呼ばれる public: // コンストラクタ及びデストラクタ dtab() {make_table(DTABSIZ);} dtab(int buckets) {make_table(buckets);} virtual ■dtab(); // テーブル操作ルーチン int hash(char *); int insert(dsyment *entry); int remove(dsyment *entry); dsyment *lookup (char *n, int nofollow=0, int kind=K_NIL); int add_subtable (dtab *subtab); // このテーブルは何か「実際」の要素を含んでいるか？ int empty(); // デバッグ情報のためのアクセスルーチン void set_slt_start(SLTPOINTER n) {slt_start = n;} void set_slt_end(SLTPOINTER n) {slt_start = n;} SLTPOINTER get_slt_start() {return slt_start;} SLTPOINTER get_slt_end() {return slt_end;} void set_ntt_start (dnttentry *ntt) {ntt_start = ntt;} void set_ntt_end (dnttentry *ntt) {ntt_end = ntt;} dnttentry *get_ntt_start () {return ntt_start;} dnttentry *get_ntt_end () {return ntt_end;} void set_sourcefile(dsrcent *x) {srcf = x;} void set_endsourcefile(dsrcent *x) {esrcf = x;} dsrcent *sourcefile() {return srcf;} dsrcent *endsourcefile() {return esrcf;} // フェイクブロックへのアクセスルーチン void set fakes(fakeblock *f) {n_fakes = f;} fakeblock *fakes() {return n_fakes;} // テーブル反復子 void iter_start(); dtab *nextsubtab(); // テーブルタイプ virtual int ttyp() = 0; // 他のメンバ及びフレンドの宣言 };

【０１２１】３．２．１．２ クラスblocktab blocktabはdtabから誘導されたクラスである。blocktab
は全てのソースブロックの基底クラスである。blocktab
は、演算子ttyp()以外は、dtabに追加して定義している
ものはない。ttyp()は関数の内側の全ての{}内部のシン
ボルを表わすのに使用される。

【０１２２】クラスblocktabを構成するクラス、データ
構造、変数及び関数を表８に示す。

【０１２３】 〈表−８〉 class blocktab : public dtab { public: // コンストラクタ blocktab() {} // テーブルタイプ virtual int ttyp(); // K_BEGIN };

【０１２４】３．２．１．３ クラスfunctab functabは、blocktabから誘導されたクラスである。fun
ctabは、関数の最も外側のブロックを表わすのに使用さ
れる。functabは関数の名前及びエイリアスを定義す
る。functabはまた名前及びエイリアスにアクセスして
修正する一組のアクセスルーチンを定義する。

【０１２５】クラスfunctabを構成するクラス、データ
構造、変数及び関数を表９に示す。

【０１２６】 〈表−９〉 class functab : public blocktab { private: char *n_name, *n_alias; // 関数の名前とエイリアス public: // コンストラクタ functab(char *n, char *a); // 名前とエイリアスへのアクセスルーチン char *name() {return n_name;} char *alias() {return n_alias;} void set_name (char *n) {n_name = n;} void set_alias (char *n) {n_alias =n;} // テーブルタイプ virtual int ttyp(); // K_FUNCTION };

【０１２７】３．２．１．４ クラスmodtab modtabはblocktabから誘導されたクラスである。modtab
は本質的にはfunctabと同じであり、代わりにfunctabか
ら誘導することができる。

【０１２８】modtabは関数ttyp()を再定義する。

【０１２９】クラスmodtabを構成するクラス、データ構
造、変数及び関数を表１０に示す。

【０１３０】 〈表−１０〉 class nulltab : public dtab { public: // コンストラクタ nulltab() {} nulltab(int buckets) : dtab(buckets) {} }; class modtab : public blocktab { private: char *n_name, *n_alias; // モジュールの名前とエイリアス public: // コンストラクタ modtab(char *n, char *a); // 名前とエイリアスへのアクセスルーチン char *name() {return n_name;} char *alias() {return n_alias;} void set_name (char *n) {n_name = n;} void set_alias (char *n) {n_alias = n;} // テーブルタイプ virtual int ttyp(); // K_MODULE };

【０１３１】３．２．１．５ クラスnulltab nulltabはdtabから誘導されたクラスである。nulltabは
最も外側のレベルのローカル及びグローバルNTTを表わ
すのに使用される。例えば、GNTTはグローバルなSVARを
全て含んでいるnulltabにより表わされる。同様に、LNT
Tの中のmodtabはnulltabの内側に包まれる。

【０１３２】クラスnulltabの主な特徴は、色々なハッ
シュテーブルサイズを与えてインスタンスを生成するこ
とができることである（テーブルが本質的にフラット
で、小さなハッシュテーブルでは多数の衝突を引き起こ
してしまうGNTTに有用である）。

【０１３３】クラスnulltabを構成するクラス、データ
構造、変数及び関数を表１１に示す。

【０１３４】 〈表−１１〉 class public : public dtab { public: // コンストラクタ nulltab() {} nulltab(int buckets) : dtab(backets) {} // テーブルタイプ virtual int ttyp(); // K_NIL };

【０１３５】３．２．２ ステップ８０６−ルックアッ
プテーブルを整合させる ステップ８０６の期間中、ルックアップテーブル整合部
７２６は、コンパイラルックアップテーブル７１８のエ
ントリをトランスレータルックアップテーブル７２０の
エントリと整合させる。

【０１３６】図９は、ルックアップテーブル整合部７２
６の動作のフローチャートを示す（換言すれば、図９は
ステップ８０６の動作の詳細フローチャートを示す）。
ステップ９０２で、ルックアップテーブル整合部７２６
はルックアップテーブル７１８、７２０をその最もコン
パクトな形態に正規化する、すなわち縮約する。

【０１３７】ステップ９０６で、ルックアップテーブル
整合部７２６はトランスレータルックアップテーブル７
２０の深さ優先の走査を行い、トランスレータルックア
ップテーブル７２０中の要素をコンパイラルックアップ
テーブル７１８中でそれに対応する要素（またはその祖
先原型のうちの１つ）と整合させる。

【０１３８】ステップ９０２及び９０６を次章で更に詳
細に説明する。

【０１３９】３．２．２．１ ステップ９０２−ルック
アップテーブルを正規化する ステップ９０２の間、ルックアップテーブル整合部７２
６は関係のないテーブルを識別して捨てる。このステッ
プを行っている間の目標は、ルックアップテーブル７１
８、７２０をその最小の大きさにまで圧縮してルックア
ップテーブル７１８、７２０の中のサブテーブルがそれ
ぞれ少くとも１つの関係のあるエントリを持つようにす
ることである。ステップ９０２でこの目標を達成するこ
とにより、ルックアップテーブル整合部７２６は、ステ
ップ９０６で入力用のルックアップテーブル７１８と７
２０をエントリ毎に整合、つまり対応させることができ
る。

【０１４０】ステップ９０２を行うに際し、ルックアッ
プテーブル整合部７２６は型エントリを無視する。ルッ
クアップテーブル整合部７２６は、変数エントリだけが
デバッグ情報の修正を必要とするので、（SVAR、DVAR及
びFPARAMのような）変数エントリにだけ注意を払う。

【０１４１】オブジェクトコードファイル１１８はトラ
ンスレータ３０２により作られたテンポラリデータにつ
いての多数のエントリを含んでいる。これらテンポラリ
データができるために、コンパイラデバッグデータ構造
５１６に入っているコンパイラデバッグ情報１２６のブ
ロック構造が変化する。例えば、トランスレータルック
アップテーブル７２０の中では空になっているテーブル
が、コンパイラルックアップテーブル７１８中では空で
はなくなっていることがある。

【０１４２】それ故、ステップ９０２の間、ルックアッ
プテーブル整合部７２６は、トランスレータ３０２が作
り出したテンポラリデータを表わすDVARを無視する。こ
のようなテンポラリデータDVARはその名前で識別するこ
とができる。本発明の好適実施例では、DVARテンポラリ
データは文字列「__[A-Z]」（すなわち、２つのアンダ
ースコア文字の次に大文字のアルファベットが続くも
の）で始まる名前を持っているとされている。

【０１４３】本発明の好適実施例では、ルックアップテ
ーブル整合部７２６はステップ９０２を行うのに表１２
に擬似コードで示すアルゴリズムを使用している。

【０１４４】 〈表−１２〉 ｆｏｒ table_root.depth-first-search() 中の各テーブル ｄｏ ｉｆ table.empty() ｔｈｅｎ ＃ このテーブルを消去する このテーブルの全要素を親テーブル中にコピーする このテーブルへの親テーブルからのリンクポインタを このテーブルのサブテーブルのリストで置換する ｅｎｄｉｆ ｅｎｄｆｏｒ

【０１４５】ルックアップテーブル整合部７２６は、テ
ーブルがSVARを含まずかつテーブルに入っているDVARが
トランスレータ３０２で作られたテンポラリデータであ
れば、テーブルが空であるとみなす。

【０１４６】３．２．２．２ ステップ９０６−深さ優
先の走査を行う ステップ９０６の間、ルックアップテーブル整合部７２
６はトランスレータルックアップテーブル７２０のエン
トリをコンパイラルックアップテーブルのそれに対応す
るエントリと整合させる。ステップ９０６を行うには、
ルックアップテーブル整合部７２６は２つのルックアッ
プテーブル７１８と７２０に対して並列、深さ優先の走
査を行う。

【０１４７】本発明の好適実施例では、ルックアップテ
ーブル整合部７２６はステップ９０６を行うのに表１３
に疑似コードで示したアルゴリズムを使用する。

【０１４８】 〈表−１３〉 match_tables (dtab *cpp_tab, dtab *ctab) { cpp_tab と c_bab の互に対応するフィールドを指示する ｆｏｒ cpp_tab の各子 ｄｏ c_tab の次の子を得る matching_tables (cpp_tab_child, c_tab_child); ｅｎｄｆｏｒ }

【０１４９】表１３に示したアルゴリズムは、コンパイ
ラルックアップテーブル７１８とトランスレータルック
アップテーブル７２０の双方において、対応するテーブ
ル（関数やローカルブロック等に対するもの）が正確に
同じ順序で現われるという仮定のもとに動作する。この
仮定はステップ９０２により保証される。

【０１５０】３．２．３ ステップ８１０−調整を行う ステップ８１０を行うには、ルックアップテーブル調整
部７４４は整合済みトランスレータルックアップテーブ
ル７３４に対しての深さ優先走査を行う。

【０１５１】整合済みトランスレータルックアップテー
ブル７３４だけに対して走査が行われる。整合済みトラ
ンスレータルックアップテーブル７３４の中の各サブテ
ーブルの各エントリを整合済みコンパイラルックアップ
テーブル７３２の中の対応するサブテーブル内で探す。
このようなエントリが整合済みコンパイラルックアップ
テーブル７３２内に存在しなければ、トランスレータル
ックアップテーブル７３４の中のこのエントリに対応す
るDNTTエントリに削除用の印を付ける。その他の場合に
は、整合済みコンパイラルックアップテーブル７３２か
らの情報を整合済みトランスレータルックアップテーブ
ル７３４にコピーする。

【０１５２】ルックアップテーブル調整部７４４が整合
ルックアップテーブル７３２と７３４の間で情報をコピ
ーするやり方を次の章で詳細に説明する。

【０１５３】３．２．３．１ DNTTフィールド値 整合済みコンパイラルックアップテーブル７３２に対応
するエントリが見つかると、ルックアップテーブル調整
部７４４は可能な全ての情報を整合済みトランスレータ
ルックアップテーブル７３４のエントリにコピーする。
具体的には、DVAR及びFPARAMのエントリについては、ル
ックアップテーブル調整部７４４は、スタックオフセッ
ト値及びレジスタフラブ値をコピーする。

【０１５４】SVARエントリについては、ルックアップテ
ーブル調整部７４４は、シンボルロケーション値につい
ての将来の決定用情報を設定し、シンボルオフセット
値、変位値及びロケーション値をコピーする。

【０１５５】FUNCエントリについては、ルックアップテ
ーブル調整部７４４は、entryaddr値、最適化フィール
ド値、lowaddrフィールド値及びhiaddrフィールド値を
コピーする。実現の仕方によっては、ルックアップテー
ブル調整部７４４は、これらフィールドについての決定
用情報を設定してもよい。

【０１５６】OBJECT_IDエントリについては、ルックア
ップテーブル調整部７４４はobject_identフィールド値
についての決定用情報を設定する。

【０１５７】３．２．３．２． SLT ルックアップテーブル調整部７４４は、対応するDNTT_B
EGIN/DNTT_END対をSLT_BEGIN/SLT_END対と整合させる。
ルックアップテーブル調整部744はまた、MODULE対及びF
UNCTION対を整合させる。そのように整合させることが
できないSLTまたはDNTT BEGIN/ENDエントリは、削除の
目標である（ただし下の説明を参照）。

【０１５８】また、ルックアップテーブル調整部７４４
は、SLT_CLASS_SCOPEエントリ及びSLT_WITHエントリ
（及びそれに対応するSLT_END)を挿入し、対応するDNTT
エントリを整合させる。コンパイラ１１４はこれらのエ
ントリを出力しない。それは、それらがトランスレータ
デバッグ情報３０６に固有のものであるからである。

【０１５９】また、ルックアップテーブル調整部７４４
は、余分のSLT_BEGIN/SLT_END対を挿入して、関数内部
のクラス宣言に包まれているDNTT_BEGIN/DNTT_END対と
整合させる。これらは決して削除してはならない。

【０１６０】上述の操作を行うには、ルックアップテー
ブル調整部７４４は最初に初期SLTを設定し、次にSLTを
増加する。これら２つのステップについて次の章で詳細
に説明する。

【０１６１】３．２．３．２．１ 初期SLTを設定する 表６及び表７に示すように、テーブルノードは２つのSL
Tポインタ用フィールドを含んでいる。１つはSLT_BEGIN
（またはFUNCTIONまたはMODULE）へのポインタであり、
もう１つはブロックを区切るDNTTに対応するSLT_ENDへ
のポインタである。

【０１６２】これらノードは、整合済みコンパイラルッ
クアップテーブル７３２については正しく設定される
が、トランスレータルックアップテーブル７３４につい
ては正しく設定されない。ルックアップテーブル調整部
７４４は、下記のステップを行って整合済みトランスレ
ータルックアップテーブル７３４についてのこれらノー
ドを設定する。

【０１６３】最初に、ルックアップテーブル調整部７４
４は、整合済みトランスレータルックアップテーブル７
３４についての修正のためのSLTのコピーを、整合済み
コンパイラルックアップテーブル７３２から作る。この
コピー中のDNTT逆方向ポインタはクリアされる。

【０１６４】調整ステップ８１０の間（ルックアップテ
ーブル調整部７４４は、この動作の間は挿入や削除を行
わない）、ルックアップテーブル調整部７４４は、整合
済みコンパイラルックアップテーブル７３２中の対応す
るエントリが指すものと同じオフセットにある対応する
SLTエントリを指すように、整合済みトランスレータル
ックアップテーブル７３４を設定する（また、勿論、こ
れら新しいSLTエントリに対する対応する逆方向ポイン
タを設定する）。

【０１６５】これら２つのステップが終了してからも、
幾つかの未整合DNTT_BEGIN/DNTT_END対と、おそらくは
幾つかの未整合SLT_BEGIN/SLT_END対が存在することが
ある。ルックアップテーブル調整部７４４はこれらを削
除の目標とする。

【０１６６】また、ルックアップテーブル調整部７４４
は、幾つかのSLT_BEGIN及びSLT_FUNCTIONノードに或る
特別の印を設定し、これにより、後のSLT増加操作を行
う段階で何等かのノードを生成してそれらのノードの回
りに挿入しなければならないことを示す。

【０１６７】３．２．３．２．２ SLTを増加する 上に記したように、或るDNTTノードについて、ルックア
ップテーブル調整部７４４はSLTエントリを生成する。
これらDNTTノードには以下の２つの種類がある。

【０１６８】第１のものは、DNTT_CLASS_SCOPE及びDNTT
_WITHノードである。これらはクラスのメンバ関数に対
するDNTT_FUNCノードの前及び後に来る（それらに対応
するDNTT_ENDもまた関数のDNTT_ENDを括る）。

【０１６９】第２のものは、特別に印の付いたDNTT_BEG
IN及びDNTT_ENDノードである。これらは、関数内部のロ
ーカルクラス宣言を取り囲むものとして出力される。こ
れらノードは、普通のBEGIN及びENDとしては処理されな
い（すなわち、これらについてはテーブルが作られな
い）。

【０１７０】第１の場合については、ルックアップテー
ブル調整部７４４は、DNTT_FUNCの未使用フィールド
に、関数の前のDNTT_CLASS_SCOPEの有無及び関数の後の
DNTT_WITHの有無について１ビットづつ、合計２ビット
の印を付ける。

【０１７１】第２の場合については簡単な印を付けるこ
とは不可能である。各々がDNTT_FUNCTION/DNTT_END対の
内部（すなわち、ローカルブロックの内側で宣言された
クラス）ではなく、DNTT_BEGIN/DNTT_END対の内部に現
われる、任意の個数のBEGIN/END対が存在できる。

【０１７２】模造ブロック（fake block）という概念
は、これらの状況を取扱うのに使用される。

【０１７３】模造ブロックは「現実のブロック」と同じ
であるが、テーブル構築ステップ８０２の間、ルックア
ップテーブル構築部７１０、７１２が印の付いたBEGIN
（またはこのような印の付いたBEGINに対応するEND）を
見つけたとき、ルックアップテーブル構築部が別個のテ
ーブルスタックにプッシュダウンしたりポップアップす
る点だけが違う。最後のこのようなエントリがポップア
ップされると、サブトリー全体が直ぐ外側の「現実の」
テーブルに取付けられる。

【０１７４】SLTを埋め盡すには、ルックアップテーブ
ル調整部７４４は、SLTを走査してこれを１エントリづ
つ新しいコピーに転写する。ルックアップテーブル調整
部７４４は、役に立たないSLTエントリ（例えば、DNTT_
SRCFILEに対応しなかったSLT_SRCFILE)を捨て、上述の
ように幾つかのSLTエントリを挿入する。

【０１７５】ルックアップテーブル調整部７４４は、加
除されたSLTエントリの数のカウンタを保持している。S
LT_SPECIALが現われると、ルックアップテーブル調整部
７４４は、DNTTを逆方向に指示するそのDNTTPOINTERに
従い、このオフセットカウンタをそのSLTPOINTERに加え
る。

【０１７６】SLTへの各エントリについて、ルックアッ
プテーブル調整部７４４は次の処置を取る。

【０１７７】SLT_NORMALエントリについては、ルックア
ップテーブル調整部７４４は、これらを整合済みトラン
スレータルックアップテーブルにコピーし、両インデク
スを１だけインクリメントさせる。

【０１７８】SLT_SRCFILEエントリについては、DNTT逆
方向ポインタがDNTT_NTLであれば、ルックアップテーブ
ル調整部７４４はこのSLT_SRCFILEエントリを捨て、オ
フセットカウンタをデクリメントさせる。その他の場合
には、ルックアップテーブル調整部７４４はDNTT逆方向
ポインタを整合済みトランスレータルックアップテーブ
ル７３４にコピーする（そして逆方向ポインタにより指
示されているDNTTエントリを調節する）。

【０１７９】SLT_BEGINエントリについては、DNTT逆方
向ポインタがDNTT_NILであれば、ルックアップテーブル
調整部７４４はこのSLT_BEGINエントリを捨て、オフセ
ットカウンタをデクリメントさせる。

【０１８０】その他の場合には、ルックアップテーブル
調整部７４４はノードをコピーする。ルックアップテー
ブル調整部７４４は次にこのノードにより指示されてい
るDNTT_BEGINを調べる。調整ステップ８１０の間、ルッ
クアップテーブル調整部７４４は模造ブロックテーブル
のトリーのコピーをDNTT_BEGINの終りの未使用のパディ
ングワードに格納する。このノードが０でなければ、ル
ックアップテーブル調整部７４４は模造ブロックトリー
の深さ優先の走査を行う。

【０１８１】模造ブロックトリーの深さ優先の走査を行
いながら、ルックアップテーブル調整部７４４は、下降
途中で出逢う各テーブルについてSLT_BEGINを作る。こ
れらノードについてのDNTTポインタは模造ブロックノー
ドに格納され、DNTTからSLTへの前進及び後退リンクを
設定するのに使用される。ルックアップテーブル調整部
７４４は次にオフセットカウンタをインクリメントさせ
る。

【０１８２】ルックアップテーブル調整部７４４はま
た、上昇の途中で各テーブルについてのSLT_ENDを作
り、これに同様にパッチを当て、オフセットカウンタを
インクリメントさせる。

【０１８３】SLT_FUNCTIONエントリについては、ルック
アップテーブル調整部７４４は、これらのSLTエントリ
に対応するDNT_FUNCTIONエントリを追跡して位置を突き
とめる。ルックアップテーブル調整部７４４は、DNTT_C
LASS_SCOPE及び／またはDNTT_WITHの存在を示すフラグ
がないかどうかチェックする。

【０１８４】クラススコープに関するフラグが設定され
ていれば、ルックアップテーブル調整部７４４はSLT_CL
ASS_SCOPEを生成してオフセットカウンタをインクリメ
ントさせる。ルックアップテーブル調整部７４４はDNTT
_FUNCTIONから後向きに探し、DNTT_CLASS_SCOPEの位置
を突きとめてこれを整合させる。

【０１８５】次に、ルックアップテーブル調整部７４４
は、SLT_FUNCTIONノード全体をコピーし、DNTT_FUNCTIO
NのSLTポインタを、オフセットカウンタにより調節す
る。

【０１８６】DNTT_WITHフラグが設定されていれば、ル
ックアップテーブル構築部７４４は、SLT_WITHを生成
し、同様にDNTT_WITHを捜し出して前進・後退ポインタ
を設定する。

【０１８７】最後に、ルックアップテーブル構築部７４
４は模造ブロックがないかどうかチェックし、DNTT_BEG
INに対するのと同じ手続を取る。

【０１８８】SLT_ENDエントリについては、DNTT逆方向
ポインタがDNTT_NILであれば、ルックアップテーブル構
築部７４４はこのエントリを捨て、オフセットカウンタ
をデクリメントさせる。そうでない場合には、ルックア
ップテーブル構築部７４４は、（それに対応したDNTT_E
NDを見出しそのbeginscopeフィールドを調べることによ
り）そのスコープを開始した対応するDNTTをチェックす
る。対応したDNTTがDNTT_FUNCTIONであってかつclass_s
copeまたはwithフラグがセットされていれば、ルックア
ップテーブル構築部７４４がSLT_ENDを生成して既に作
られているSLT_CLASS_SCOPEまたはSLT_WITHを整合さ
せ、これに従ってポインタとオフセットカウンタにパッ
チを当てる。ルックアップテーブル構築部７４４はSLT_
FUNCTIONに対するのと同じ手法を取る。すなわち、クラ
ススコープに対してSLT_ENDを挿入し、このENDをコピー
し、withに対してSLT_ENDを挿入する。

【０１８９】SLT_MODULEエントリについては、ルックア
ップテーブル調整部７４４はエントリを完全にコピーす
る。それは１つのものしか存在しないからである。

【０１９０】上の処置が完了した後には、要素ごとにLN
TTに正しく整合つまり対応している新しいSLTが存在す
る。また、この新しいSLTには使用されていないエント
リは含まれていない。

【０１９１】３．２．３．３ DNTT_SRCFILEとSLT_SRCFI
LEを整合させる SRCFILEエントリは、デバッグ情報構成の中で最も体系
的でない部分である。SCRFILEをどこに出力するかにつ
いては、コンパイラが異れば、その方針が異なる。

【０１９２】これに加えて、ある侵すことのできないSR
CFILEエントリが存在する（例えば、FUNCTIONエントリ
の直前にあるSCRFILEエントリ）。

【０１９３】整合ルックアップテーブル７３２、７３４
中の各ノード及びテーブルは、そのノードの直前にある
SCRFILEエントリへのポインタを有している。これに加
えて、各テーブルノードは、そのテーブルのDNTT_ENDの
直前のSRCFILEへのポインタを有している。

【０１９４】ルックアップテーブル調整部７４４はこの
問題点を解決するために発見的方法を利用している。

【０１９５】調整ステップ８１０の間にトリーを走査す
ると、ルックアップテーブル調整部７４４はSRCFILEエ
ントリを飛越す（これらのエントリは帳簿付け及びデバ
ッグのためだけに整合済みトランスレータルックアップ
テーブル７３４中に存在する）。その代り、ルックアッ
プテーブル調整部７４４はテーブルに出会う毎に下記ア
ルゴリズムを使用する。

【０１９６】ステップ１：ルックアップテーブル調整部
７４４は、対応するテーブルのSRCFILEエントリを使用
して、ブロックのBEGINに対応するSRCFILEエントリを決
定する（fix up）。

【０１９７】ステップ２：ルックアップテーブル調整部
７４４は、上述のように整合済みトランスレータルック
アップテーブル７３４のサブテーブルの深さ優先の走査
を行う。

【０１９８】ステップ３：ルックアップテーブル調整部
７４４はブロックのENDに対応するSRCFILEエントリを決
定する。

【０１９９】ステップ４：整合済みトランスレータルッ
クアップテーブル７３４の各エントリについて、ルック
アップテーブル調整部７４４は、このノードにより指示
されているSRCFILEエントリを決定する。

【０２００】ルックアップテーブル調整部７４４は、FU
NCTIONまたはBEGINのノードに出逢うと、最後に見たSRC
FILEをNULLにリセットする。これは、SRCFILEが上記の
アルゴリズムのステップ１により修正されるために可能
である。

【０２０１】上の４ステップアルゴリズムが終了した
後、FUNCTIONに対応する各SRCFILEが決定される。他のS
RCFILEは、関数の内部で変化するもの以外は重要ではな
く、これらはステップ３及びステップ４でルックアップ
テーブル調整部により処理される。

【０２０２】３．２．４． ステップ８１４−整頓する ステップ８１４の間、ルックアップテーブル調整部７４
４は、削除用の印が付いているエントリを削除すること
により名前及び型テーブル（Name andType Table, NT
T）を整頓する。ルックアップテーブル調整部７４４
は、このステップの間、LNTTとGNTTの内部の相互リンク
があるため注意を払わなければならない。

【０２０３】ルックアップテーブル調整部７４４は、問
題となっているエントリを、その種類フィールドをK_NI
Lに設定することにより削除し、または無効にする。エ
ントリがDNTT_BLOCKの１個分より長ければ、２番目以降
のブロックも加工されていないDNTT_BLOCKとして処理さ
れ、その種類フィールドはK_NILに設定され、その延長
フラグは０にリセットされる（こうしてこのエントリを
幾つかの隣接したK_NILブロックのように見せる）。

【０２０４】整頓を行うには、ルックアップテーブル調
整部７４４は、DNTTに対して最後の走査を行い、「特別
に印が付けられた」DNTTエントリを全て探し、それらを
上述のように無効にする。

【０２０５】３．３ 出力オブジェクトファイルインタ
ーフェース 図５に示すように、出力オブジェクトファイルインタフ
ェース５１４は、新しいオブジェクトコード３１６を作
り、新しいオブジェクトコード３１６にオブジェクトコ
ード１２４及びトランスレータデバッグ情報３０６とコ
ンパイラデバック情報１２６の組合せを格納する。

【０２０６】出力オブジェクトファイルインターフェー
ス５１４のフローチャートを図１０に示す。出力オブジ
ェクトファイルインターフェース５１４の動作を今度は
図５、図７及び図１０を参照して説明する。

【０２０７】ステップ１００２で、出力オブジェクトフ
ァイルインターフェース５１４は最終デバッグ情報を含
むオブジェクトコード３１６用のファイルを書き込み用
に生成する。

【０２０８】ステップ１００６で、出力オブジェクトフ
ァイルインターフェース５１４はオブジェクトファイル
１２４のヘッダのためのスペースをオブジェクトコード
３１６用のファイルに残す。

【０２０９】ステップ１０１０で、出力オブジェクトフ
ァイルインターフェース５１４は、オブジェクトコード
ファイル１１８、マージ済みルックアップテーブル５２
８及びポータブル出力決定用情報５３０からの情報を、
最終デバッグ情報を含むオブジェクトコード３１６用の
ファイルに書込む。出力オブジェクトファイルインター
フェース５１４は、この情報をこのファイルに次の順序
で書込む。

【０２１０】最初に、出力オブジェクトファイルインタ
ーフェース５１４は、テキストを、次にデータを、次に
もし存在すれば、Pascalインターフェースをこのファイ
ルに書込む。

【０２１１】出力オブジェクトファイルインターフェー
ス５１４は次に、シンボルテーブルを最終デバッグ情報
を含むオブジェクトファイル３１６に書込む。これはシ
ンボルテーブルをオブジェクトコードファイル１１８か
らこのファイル３１６にコピーすることにより行われ
る。次に、シンボルが関数add_symbol()を使用して付加
される（表４及び表５）。最後に、シンボルテーブルの
サイズをオブジェクトファイルのヘッダ中で調節する。

【０２１２】出力オブジェクトファイルインターフェー
ス５１４は次にSupsym、テキスト再配置レコード及びデ
ータ再配置レコードをファイル３１６に書込む。

【０２１３】出力オブジェクトファイルインターフェー
ス５１４は次に、延長ヘッダ、デバッグヘッダ、GNTT、
LNTT、SLT及びVT（及びもしあればXT）及び別の延長部
分から成るデバッグ情報をファイル３１６に書込む。ま
た、延長ヘッダのオフセット及びサイズがオブジェクト
ファイルヘッダに記録される。

【０２１４】ステップ１０１４で、出力オブジェクトフ
ァイルインターフェース５１４は、オブジェクトファイ
ルヘッダを最終デバッグ情報を含むファイル３１６のオ
フセット０の位置に書込む。

【０２１５】本発明の好適実施例２２８では、出力オブ
ジェクトファイルインターフェース５１４はクラスの形
態で実現されている。これらクラスのインスタンスはオ
ブジェクトコード及びデバッグ情報が入っているファイ
ルを読み書きするのに使用される。

【０２１６】出力オブジェクトファイルインターフェー
ス５１４のクラスは、入力オブジェクトファイルインタ
ーフェース５０２、５０４についてのクラスと同じであ
る。これらのクラスを構成するクラス、データ構造及び
関数は表２、表３、表４及び表５に示してある。

【０２１７】出力オブジェクトファイルインターフェー
ス５１４の動作は、関数を表２、表３、表４及び表５で
示したクラスから呼出すことにより行われる。例えば、
ＨＰ９０００シリーズ３００コンピュータプラットフォ
ーム２０２上で動作するときは、関数Write_debug_info
()を使用してデバッグ情報７５０をファイル３１６に書
込む。また、関数copy()を使用してオブジェクトコード
１２４をファイル３１６に書込む。

【０２１８】４．０ デバッガ 図１１は、本発明の好適実施例２２８のデバッガ３２０
の構造図／機能フローチャートを示す。図１１で、端末
２１８及びユーザ１１１８以外は、長方形はソフトウェ
アモジュール／プロセスを表わし、長円形はソフトウェ
アモジュール／プロセスの入力及び出力を表わす。

【０２１９】図１１に示すように、デバッガ３２０は２
つのモジュール、すなわちプリプロセッサ１１０４と主
デバッガ１１１２を含んでいる。

【０２２０】プリプロセッサ１１０４は、実行可能ファ
イル３５０（実行可能ファイル３５０はオブジェクトコ
ード３１６中の最終デバッグ情報を含んでいる）を受取
り、前処理されたデバッグ情報１１０８を発生する。前
処理されたデバッグ情報１１０８は、プリプロセッサ１
１０４が重複した情報を除去し、情報の各部分間のポイ
ンタを決定し（fix up）、あるデータを特別のテーブル
（図１１には図示してない）に集めてこれを主デバッガ
１１１２が使用するように、前処理されたデバッグ情報
１１０８に追加することを除いては、オブジェクトコー
ド３１６中の最終デバッグ情報と同じである。

【０２２１】具体的には、プリプロセッサ１１０４は、
ソースファイルデスクリプタテーブル、手続デスクリプ
タテーブル、クラスデスクリプタテーブル及びアドレス
エイリアステーブル（図１１には示してない）を生成す
る。

【０２２２】ソースファイルデスクリプタテーブルに
は、生成されたコードのどの部分をソースコード１０２
にマップするかについての記述が入っている。ソースフ
ァイルデスクリプタテーブルには、ソースファイルデス
クリプタエントリが入っている。ソースファイルデスク
リプタエントリには、とりわけ、ファイルデスクリプタ
によりカバーされるコードアドレスの範囲を示す開始及
び終りのアドレスと、それからコードを生成したソース
ファイルの名前が入っている。主デバッグ１１１２が正
しく動作するには、ファイルデスクリプタにより記述さ
れるアドレス範囲が減少しないソース行レンジをカバー
しなければならない。このことは１つのソースファイル
がそれに関連する幾つかのファイルデスクリプタを備え
ることができることを意味している。

【０２２３】手続デスクリプタテーブルにはデバッグ可
能な手続及び／またはプログラム１０２の中の関数の全
ての記述が入っている。プリプロセッサ１１０４により
初期設定されるＣ＋＋特有の情報は、関数がプログラム
１０２のどこかで二重になっているか、オーバーロード
されているか、メンバ関数であるか（もしそうなら、ど
のクラスのメンバか）、コンストラクタであるか、デス
トラクタであるか、静的であるか、仮想であるか、純仮
想（pure virtual）であるか、定数であるか、インライ
ン展開されているか及び／または演算子関数であるかを
示す。

【０２２４】クラスデスクリプタテーブルは、クラスが
定義されているソースコード１０２中のソース行の範囲
を指示することにより各クラスのスコープを記述する。

【０２２５】アドレスエイリアステーブルは、ソースコ
ード１０２の単一の部分から発生されたオブジェクトコ
ード１２４の中の複数のコード部分がもしあればそれを
記述する。

【０２２６】主デバッガ１１１２は、前処理されたデバ
ッグ情報１１０８を受取る。端末２１８を介して主デバ
ッガ１１１２と連絡するユーザ１１１８の指示のもと
に、主デバッガ１１１２は、ユーザ１１１８がソースコ
ード１０２の誤りを突きとめて修正するのを、前処理さ
れたデバッグ情報１１０８を使用して支援する。

【０２２７】具体的には、主デバッガ１１１２は、前処
理されたデバッグ情報１１０８を使用して、とりわけ、
ソースコード１０２を表示し、コンパイラ１１４が発生
したソースコード１０２のアセンブリコードへの翻訳を
表示し、ソースコード１０２上での実行のフローを制御
したり変更したりし、変数の型を表示し、変数の値を観
察したり設定する。

【０２２８】デバッガ３２０の構造及び動作は従来のデ
バッガ１２２のものと同じである。しかし、本発明の好
適実施例２２８のデバッガ３２０は、オブジェクトコー
ド３１６中の最終デバッグ情報、すなわちコンパイラデ
バッグ情報１２６とトランスレータデバッグ情報３０２
を組み合わせたものの中に入っている追加情報を活用す
るという別の修正された特徴を有しているという点で、
従来のデバッガ１２２に比べて改良されている。

【０２２９】本発明の好適実施例２２８では、デバッガ
３２０は、オブジェクトコード３１６中の最終デバッグ
情報に入っているＣ＋＋関連情報を活用する多数の修正
された且つ追加的特徴を有している。

【０２３０】例えば、本発明の好適実施例２２８のデバ
ッガ３２０は、従来のデバッガ１２２では利用できなか
った別の関数の型情報を表示することができる。適用可
能なとき、この追加情報は、特定の関数が、インライン
展開される、オーバーロードされる、静的である、定数
である、または仮想であると宣言されているか否か、ま
た、関数がメンバ関数、演算子関数、コンストラクタ、
またはデストラクタとして宣言されているか否かを示
す。オブジェクトコード３１６中の最終デバッグ情報は
また、デバッガ３２０に、ソースコード１０２で宣言さ
れているが定義を与えられていない関数についての型情
報を表示できるようにする。

【０２３１】デバッガ３２０は、デバッグ情報１１０８
を使用してＣ＋＋の匿名の共用体（anonymous union）
の特徴についての備えも持っている。デバッグ情報１１
０８は、各匿名の共用体メンバを２つの形態で効果的に
指定する。１つの形態では、匿名の共用体メンバをあた
かもそれが匿名の共用体の外にあるかのように指定す
る。これによりユーザ１１１８は、匿名の共用体メンバ
を個々の変数として観察し、また修正することができ
る。

【０２３２】もう１つの形態は、匿名の共用体メンバを
匿名の共用体のメンバとして指定することである。これ
によりユーザ１１１８は、匿名の共用体についての型及
びデータ情報を全体的に観察することができる。

【０２３３】所与の匿名の共用体の全てのメンバは、オ
ブジェクトコード３１６中の最終デバッグ情報中では構
造体のリンク付きリストとして表わされ、そのリストの
各ノードがそのメンバについての情報を指定し且つ匿名
の共用体の外則のその形態のメンバへのポインタを含ん
でいる。例えば、３つのメンバを有するローカルな匿名
の共用体は、これら３つのメンバが匿名の共用体の一部
でなかった場合と同じになるデバッグ情報を有する。そ
れで、匿名共用体の追加デバッグ情報は、それぞれこれ
ら３つのメンバに対するデバッグ情報を指示する３つの
構造体のリンク付きリストを所持する。

【０２３４】デバッガ３２０はまた、クラス内部で定義
された列挙型への備えも持っている。この特徴は、匿名
の共用体に対するのと同じ仕方で実現される。各列挙型
のメンバは２つの形態で表わされる。１つの形態では、
特定の列挙型について宣言された列挙型メンバのリスト
の一部として表される。第２の形態では、各列挙型メン
バは、それがあたかもそれが見つかったクラスの個別メ
ンバであるかのように表わされる。第１の形によりユー
ザ１１１８は、それがどのクラスで見つかるかを指定す
るという限定だけで各列挙型メンバを個別に使用するこ
とができる。

【０２３５】デバッガ３２０はまた、ソースコード１０
２の所与の部分に結び付いた複数の同一コード部分につ
いての備えも持っている。

【０２３６】例えば、Ｃ＋＋では、ソースコード１０２
のある特定のソースファイル中で定義されたメンバ関数
をソースコード１０２の他のソースファイルにインクル
ードすることができる。

【０２３７】このメンバ関数は、ソースコード１０２中
では１つしか存在しないが、トランスレータ１０６がこ
れを翻訳してコンパイラ１１４かコンパイルするための
中間ソースコード１１０になったときには複数箇所に対
応したコードができている。。すると、コンパイラ１１
４により作られるところの、オブジェクトコード１２４
及びコンパイラデバッグ情報１２６を含むオブジェクト
コードファイル１１８中では、この同じメンバ関数に対
応する複数のコード部分が含まれる。

【０２３８】プリプロセッサ１１０４は、これら複数の
コード部分の各々についてのアドレス範囲を、オブジェ
クトコード３１６中の最終デバッグ情報から集めてアド
レスエイリアステーブルに入れ、前処理されたデバッグ
情報１１０８の中のこのテーブルをデバッガ１１１２に
渡す。アドレスエイリアステーブル内の各エントリは、
１つのコード部分の先頭と最後のアドレスとそのエイリ
アスであるテーブル内の他の全てのコード部分エントリ
を示す情報とを含んでいる。

【０２３９】デバッガ１１１２がコードアドレスに関係
する動作を行うと、このアドレスエイリアステーブルを
参照して、この所与のコードアドレスのエイリアスであ
る個々のアドレスを全て発見することができる。コード
アドレスがアドレスエイリアステーブル内のあるエント
リのアドレス範囲内に入っていれば、デバッガ１１１２
は、このエントリの開始アドレスからこの所与のアドレ
スまでのオフセットを計算する。次いで、計算されたオ
フセット値をコード部分の各々のエイリアスの開始アド
レスに加えることにより、所与のコードアドレスのエイ
リアスであるアドレスの集合を計算で求めることができ
る。

【０２４０】また、デバッガ３２０はクラススコープへ
の備えも持っている。ユーザ１１１８は、Ｃ＋＋構文に
従ってクラスを明示的に宣言することにより、コマンド
式中で使用するクラスメンバを指定することができる。
例えば、メンバはA::Bとして与えることができる。ここ
で、Aはクラスであり、BはクラスAのメンバである。ク
ラス及び、必要な場合は、クラスオブジェクトが、現在
観察しているロケーションにより暗黙のうちに決まるの
であれば、ユーザ１１１８はクラス名を明示的に宣言す
る必要はない。クラススコープがそれを暗黙のうちに決
めるからである。

【０２４１】これらの場合には、ソースコード１０２中
で観察されているロケーションは、ファイル記述テーブ
ルから決まるコードアドレスにマッピングされる。この
コードアドレスは、手続デスクリプタテーブルから決ま
る関数にマッピングされる。この関数は、デバッガ３２
０がクラス自身、その基底クラス及びそのスコープに関
して必要とする全ての情報を指すクラスデスクリプタテ
ーブル内のクラスにマッピングされる。

【０２４２】デバッガ３２０はまた、クラスメンバへの
ポインタを取り扱うに当たっては、このようなポインタ
に割当てられた値及びこのようなポインタをプリントす
ることにより表示される値が、数値の値ではなくクラス
識別子及びメンバ識別子それ自身を使用するようにす
る。例えば、Pと呼ばれるクラスメンバへのあるポイン
タの値をプリントすると、 P=&M::N が表示される。ここでMはクラスであり、NはクラスMの
メンバである。内部的に、ポインタは、数値定数のオフ
セットとして表わされるが、追加クラスデバッグ情報を
用いて、デバッガ１１１２は、どのクラスメンバにこの
数値が対応するかを判定し、この数値の代りに実際の識
別子をプリントするかを決定することができる。

【０２４３】デバッガ３２０はまた、インスタンスブレ
ークポイントを取り扱う。すなわち、デバッガ３２０
は、ユーザ１１１８がメンバ関数でブレークポイントを
設定して、関数が特定のオブジェクトに対して呼出され
た場合にのみこのブレークポイントが認識されるように
することができる。

【０２４４】デバッガ３２０はこの動作を、オブジェク
トのアドレスをブレークポイント自身と共に保存するこ
とにより行う。ブレークポイントに行き当たると、デバ
ッガ３２０は、前処理されたデバッグ情報１１０８の助
けを借りて、それについてこの関数が呼出されたオブジ
ェクトのアドレスを判定し、このアドレスを格納されて
いるアドレスと比較し、両者が等しい場合に限りデバッ
ガの実行をサスペンドする。それ以外の場合には、デバ
ッガはそのまま動作を続け、ユーザ１１１８から見て、
実行の中止は起こらない。

【０２４５】デバッガはまた、オブジェクトが定義され
ている範囲を離れて実行が進行しようとしたとき、イン
スタンスブレークポイントを自動的に削除するための備
えを持っている。

【０２４６】オブジェクトのスコープを決定することが
できる場合には、デバッガ３２０はまた、トリガブレー
クポイントと呼ばれる別のブレークポイントを、オブジ
ェクトコード内の、実行がこのスコープを離れようとす
る地点に設定する。このブレークポイントに行き当る
と、それが関連しているインスタンスブレークポイント
とこのトリガブレークポイント自身の双方が取除かれて
実行が継続する。

【０２４７】デバッガ３２０はまた、クラスブレークポ
イントも取り扱う。オブジェクトコード３１６中の最終
デバッグ情報は所与のクラスの及びそのクラスの基底ク
ラスのメンバ関数を示すので、デバッガ３２０を使え
ば、ユーザ１１１８はただ１つのコマンドを使うだけ
で、１つの特定のクラスの全てのメンバ関数に関するブ
レークポイントを設定することができる。このクラスブ
レークポイントは、クラスのどんなメンバ関数が呼出さ
れたときでもオブジェクトコードの実行をサスペンドさ
せる。

【０２４８】また、デバッガ３２０を使うことにより、
ユーザ１１１８はソースコード１０２中のあるロケーシ
ョンを見たりあるいはそこにブレークポイントを設定し
たいとき、クラス名を指定することによりソースコード
１０２の中の当該ロケーションを指定することができ
る。例えば、ユーザ１１８がクラスCのメンバである関
数fを見たい場合、このロケーションを、観察コマンド
の引数としてC::fとして指定することができる。デバッ
ガ３２０は、この動作を、クラスデスクリプタテーブル
を参照して現在のスコープ中で見える与えられた名前を
使ってクラスを判定することにより行う。デバッガ３２
０は次に、手続デスクリプタテーブルを参照し、そのデ
スクリプタが以前にクラスデスクリプタテーブルの中で
突き止められたエントリを逆方向に参照するところの、
与えられた名前を持つ関数を探す。

【０２４９】デバッガ３２０はまた、オーバーロード関
数の任意の集合についての操作をグループとして取り扱
う。ユーザ１１１８は、特定の名前を持つオーバーロー
ド関数の型情報を、もし必要ならばクラス名を限定する
ことにより、プリントするように、デバッガ３２０に要
求することができる。同様に、ユーザ１１１８は、特定
の名前を持つ全てのオーバーロード関数に対して、また
必要ならば関数のクラス名を特定のものに限定して、ブ
レークポイントを設定することもできる。デバッガ３２
０は、プリプロセッサ１１０４がオブジェクトコード３
１６中の最終デバッグ情報から作り出した手続デスクリ
プタテーブルに現われるオーバーロード関数に関する情
報を使用する。

【０２５０】なお、本願の開示の一部は著作権保護を受
けるべき資料（具体的には表などに示された各種のコー
ド）を含んでいる。著作権者は、それが特許庁の包袋ま
たは記録に現われている限り、何人による特許開示の複
写にも異議を唱えるものではないが、それ以外の場合に
ついては全ての著作権を留保する。

【０２５１】

【効果】以上詳細に説明したように、本発明によれば、
トランスレータを使って一旦翻訳した後コンパイルする
タイプの言語でかかれたコードのシンボリックデバッグ
を、このようなトランスレータを解さないコンパイラ言
語で書かれたコードの場合と同じ様に行うことができる
ようになる。

【図面の簡単な説明】

【図１】本発明の適用対象であるトランスレータベース
のコンパイルシステムの構成例を説明する図。

【図２】コンピュータシステム全般のハードウエア及び
ソフトウエア構成を説明する図。

【図３】本願発明の一実施例の概略構成を説明する図。

【図４】図３中のトランスレータの構造を説明する図。

【図５】図３中のマージャの構造を説明する図。

【図６】図３中のマージャのフローチャート。

【図７】図５中のデバッグ情報マニピュレータの構造を
説明する図。

【図８】図５中のデバッグ情報マニピュレータのフロー
チャート。

【図９】図７中のルックアップテーブル整合部のフロー
チャート。

【図１０】図５中の出力オブジェクトファイルインター
フェースのフローチャート。

【図１１】図３中のデバッガの構造を説明する図。

【符号の説明】

１００：コンパイルシステム １０２：ソースコード １０６：トランスレータ １１０：中間ソースコード １１４：コンパイラ １１８、１３４：オブジェクトコードファイル １２２、３２０：デバッガ １２４、３１６：オブジェクトコード １２６：コンパイラデバッグ情報 １２８：リンカ １３２、３５０：実行可能ファイル ２０２：コンピュータプラットフォーム ２０４：オペレーティングシステム ２０６：マイクロ命令コード ２０８：ハードウエアユニット ２１０：ＲＡＭ ２１２：ＣＰＵ ２１４：入出力インターフェース ２１８：端末 ２２２：データストレージ ２２６：プリンタ ２２８：アプリケーションプログラム ３０６：トランスレータデバッグ情報 ３１２：マージャ ４０２：スキャナ／パーザ ４０６：意味情報／内部データ構造 ４１０：デバッグ情報生成部 ４１８：コード生成部 ５０２、５０４：入力オブジェクトファイルインターフ
ェース ５１０：デバッグ情報マニピュレータ ５１４：出力オブジェクトファイルインターフェース ５１６：コンパイラデバッグデータ構造 ５１８：トランスレータデバッグデータ構造 ５２８：マージ済みルックアップテーブル ５３０：ポータブル出力決定用情報 ７１０、７１２：ルックアップテーブル構築部 ７１８：コンパイラルックアップテーブル ７２０：トランスレータルックアップテーブル ７２６：ルックアップテーブル整合部 ７３２：整合済みコンパイラルックアップテーブル ７３４：整合済みトランスレータルックアップテーブル ７４０：ポータブル入力決定情報 ７４４：ルックアップテーブル調整部 １１０４：プリプロセッサ １１０８：前処理されたデバッグ情報 １１１２：主デバッガ １１１８：ユーザ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ミチェイ・メータ アメリカ合衆国カリフォルニア州サンノ ゼ・ディープ・クリーク・コート 1856 (72)発明者 マーク・ダブリュー・マクドウエル アメリカ合衆国コロラド州フォート・コ リンズ・ソルスティス・レイン 1261 (72)発明者 マノジ・ダドゥ アメリカ合衆国カリフォルニア州サンノ ゼ・グレンロイ・ドライブ 1650 (72)発明者 ブルーノ・メリ アメリカ合衆国コロラド州フォート・コ リンズ・キャプストーン・フォート 4030 (56)参考文献 特開 昭59−180756（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 11/28

Claims (15)

(57)【特許請求の範囲】
1. 【請求項１】以下の(a)ないし(c)を設け、トランスレー
   タベースのソフトウエアコンパイラでの使用に適合する
   ように、ソースコードのシンボリックデバッグ情報を生
   成するシステム： (a) ソースコードについてのトランスレータデバッグ情
   報を生成する第１手段； (b) 前記ソースコードについてのコンパイラデバッグ情
   報を生成する第２手段； (c) 前記トランスレータデバッグ情報と前記コンパイラ
   デバッグ情報をマージして前記ソースコードに対する最
   終的なデバッグ情報を形成する第３手段。
2. 【請求項２】前記第２手段は 前記ソースコードについてのオブジェクトコードを生成
   する手段と、 前記オブジェクトコード及び前記コンパイラデバッグ情
   報を第１オブジェクトコードファイルに格納する手段を
   有することを特徴とする請求項１記載のシステム。
3. 【請求項３】前記最終的なデバッグ情報を用いて前記ソ
   ースコード中の誤りを見出す第４手段を設けたことを特
   徴とする請求項１または２記載のシステム。
4. 【請求項４】前記第４手段は前記見出された前記ソース
   コード中の誤りを修正することを特徴とする請求項３記
   載のシステム。
5. 【請求項５】前記第４手段は、 関数の型情報の表示、 匿名の共用体のメンバの指定、 クラス内で定義された列挙型のメンバの指定、 複数の同一のコードセグメントの識別、 クラススコープに基づくメンバの識別、 インスタンスブレークポイントの実現、 クラスメンバへのポインタの記号表示、 クラスブレークポイントの実現、及び オーバーロードさ
   れた関数の集合についてのグループ操作を行うことがで
   きることを特徴とする請求項３または４記載のシステ
   ム。
6. 【請求項６】 前記ソースコードが中間的にコンパイルさ
   れたものである中間ソースコードを生成する手段を設け
   たことを特徴とする請求項１記載のシステム。
7. 【請求項７】 前記ソースコードはＣ＋＋言語で書かれて
   おり、前記中間ソースコードはＣ言語で書かれているこ
   とを特徴とする請求項６記載のシステム。
8. 【請求項８】 前記第３手段は以下の(1)ないし(3)を設け
   たことを特徴とする請求項２記載のシステム： (1) 前記トランスレータデバッグ情報及び前記コンパイ
   ラデバッグ情報から第１デバッグデータ構造及び第２デ
   バッグデータ構造を生成する第４手段； (2) 前記第１デバッグデータ構造及び前記第２デバッグ
   データ構造から、前記最終的なデバッグ情報を含むマー
   ジ済みルックアップテーブルを生成する第５手段； (3) 前記オブジェクトコード及び前記最終的なデバッグ
   情報を第２オブジェクトコードファイルにストアする第
   ６手段。
9. 【請求項９】 前記第５手段は以下の(4)ないし(6)を有す
   ることを特徴とする請求項８記載のシステム： (4) 前記第１デバッグデータ構造及び前記第２デバッグ
   データ構造から第１ルックアップテーブル及び第２ルッ
   クアップテーブルを生成する手段； (5) 前記第１ルックアップテーブル中のエントリと前記
   第２ルックアップテーブル中のエントリを対応付ける手
   段； (6) 前記コンパイラデバッグ情報の一部を前記第２ルッ
   クアップテーブルから前記第１ルックアップテーブルに
   コピーする手段であって、前記第１のルックアップテー
   ブルは前記マージ済みルックアップテーブルを含む、手
   段。
10. 【請求項１０】 以下の(1)ないし(3)を設け、トランスレ
    ータデバッグ情報とコンパイラデバッグ情報をマージし
    てソースコードについての最終的なデバッグ情報を形成
    する、前記ソースコードからのオブジェクトコードに使
    用するのに適合されたコンピュータを用いて構成された
    システム： (1) 前記トランスレータデバッグ情報及び前記コンパイ
    ラデバッグ情報から第１デバッグデータ構造及び第２デ
    バッグデータ構造を生成する第１手段； (2) 前記第１デバッグデータ構造及び前記第２デバッグ
    データ構造から、最終的なデバッグ情報を含むマージ済
    みルックアップテーブルを生成する第２手段； (3) 前記オブジェクトコード及び前記最終的なデバッグ
    情報を第２オブジェクトコードファイルにストアする第
    ３手段。
11. 【請求項１１】 前記第２手段は前記第１デバッグデータ
    構造及び前記第２デバッグデータ構造から第１ルックア
    ップテーブル及び第２ルックアップテーブルを生成する
    手段、及び 前記第１ルックアップテーブルのエントリと
    前記第２ルックアップテーブルのエントリを対応付ける
    手段を有し、 前 記コンパイラデバッグ情報の一部を前記第２ルックア
    ップテーブルから前記第１ルックアップテーブルにコピ
    ーし、前記第１のルックアップテーブルは前記マージ済
    みルックアップテーブルを含むことを特徴とする請求項
    １０記載のシステム。
12. 【請求項１２】 以下の(a)ないし(d)のステップを設け、
    トランスレータデバッグ情報とコンパイラデバッグ情報
    をマージしてソースコードについての最終的なデバッグ
    情報を形成する、前記ソースコードからのオブジェクト
    コードに使用するのに適合された方法： (a) 前記トランスレータデバッグ情報及び前記コンパイ
    ラデバッグ情報を読み出すステップ； (b) 前記トランスレータデバッグ情報及び前記コンパイ
    ラデバッグ情報から第１デバッグデータ構造及び第２デ
    バッグデータ構造を生成するステップ； (c) 前記第１デバッグデータ構造及び前記第２デバッグ
    データ構造から、前記最終的なデバッグ情報を含むマー
    ジ済みルックアップテーブルを生成するステップ； (d) 前記オブジェクトコード及び前記最終的なデバッグ
    情報をオブジェクトコードファイルヘッダを有するオブ
    ジェクトコードファイルにストアするステップ。
13. 【請求項１３】 前記ステップ(c)は以下のステップ(c-1)
    ないし(c-5)を有することを特徴とする請求項１２記載
    の方法： (c-1) 前記第１デバッグデータ構造及び前記第２デバッ
    グデータ構造から第１ルックアップテーブル及び第２ル
    ックアップテーブルを生成するステップ； (c-2) 前記第１ルックアップテーブルのエントリと前記
    第２ルックアップテーブルのエントリを対応付けるステ
    ップ； (c-3) 前記コンパイラデバッグ情報の一部を前記第２ル
    ックアップテーブルから前記第１ルックアップテーブル
    へコピーするステップ； (c-4) 前記第１ルックアップテーブル中のエントリを削
    除のためにマークを付けるステップ； (c-5) 前記第１ルックアップテーブル中の前記マークを
    付けられたエントリを削除するステップであって、前記
    第１ルックアップテーブルが前記マージ済みルックアッ
    プテーブルを含む、ステップ。
14. 【請求項１４】 前記ステップ(c-2)は以下のステップ(c-
    2-1)及び(c-2-2)を含むことを特徴とする請求項１３記
    載の方法： (c-2-1) 前記第１ルップアップテーブル及び前記第２ル
    ックアップテーブルをそれぞれが有する階層構造中にお
    いて前記ソースプログラム中の変数情報を含まない要素
    を削除することによって縮小するステップ； (c-2-2) 前記第１ルックアップテーブルを前記第１ルッ
    クアップテーブルが有する階層構造に従って深さ優先走
    査するステップ。
15. 【請求項１５】 前記ステップ(d)は以下のステップ(d-1)
    ないし(d-4)を含むことを特徴とする請求項１３記載の
    方法： (d-1) 前記オブジェクトコードファイルを書き込み可能
    なようにオープンするステップ； (d-2) 前記オブジェクトコードファイル中にヘッダ領域
    を定義するステップ； (d-3) 前記オブジェクトコード及び前記マージされたル
    ックアップテーブルからの情報を前記オブジェクトコー
    ドファイル中であって前記ヘッダ領域以外の箇所にスト
    アするステップ； (d-4) 前記オブジェクトコードファイルヘッダを前記前
    記ヘッダ領域中にストアするステップ。