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

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 【０００１】 【産業上の利用分野】本発明は、トランスレータベース
のソフトウェアコンパイルシステムで意味のあるシンボ
リックデバッグ情報を発生するコンピュータシステム及
び方法に関する。 【０００２】 【従来技術及びその問題点】図１は、従来のトランスレ
ータベースのコンパイルシステム１００の構造図／機能
フローチャートを示す。図１で、長方形はソフトウェア
モジュール／プロセスを表わし、長円形はソフトウェア
モジュール／プロセスの入力及び出力を表わす。 【０００３】図１に示すように、従来のトランスレータ
ベースのコンパイルシステム１００は、トランスレータ
１０６、コンパイラ１１４、リンカ１２８及びデバッガ
１２２を含んでいる。 【０００４】トランスレータ１０６は、ソースコード１
０２（例えば、Ｃ＋＋言語で書かれている）を中間ソー
スコード１１０（例えば、Ｃ言語で書かれている）に翻
訳する。コンパイラ１１４は、中間ソースコードをコン
パイルし、オブジェクトコード１２４及びコンパイラデ
バッグ情報１２６を発生する。オブジェクトコード１２
４及びコンパイラデバッグ情報１２６は、オブジェクト
コードファイル１１８に格納される。 【０００５】リンカ１２８は、オブジェクトコードファ
イル１１８を他のオブジェクトコードファイル１３４と
リンクして実行可能ファイル１３２を作製する。実行可
能ファイル１３２にはオブジェクトコード１２４及びコ
ンパイラデバッグ情報１２６が入っている。 【０００６】コンパイラデバッグ情報１２６は、これを
ソースコード１０２の誤りを突きとめて修正する（すな
わち、ソースコード１０２を「デバッグする」）のに使
用することができるので非常に重要である。特に、ユー
ザ（図１には示してない）の監督のもとで、テバッグ１
２２はオブジェクトコード１２４及びコンパイラデバッ
グ情報１２６が入っている実行可能ファイル１３２を受
取り、デバッグ情報１２６を使用してソースコード１０
２をデバッグする。 【０００７】しかし、従来のトランスレータベースのコ
ンパイルシステム１００では、コンパイラ１１４はソー
スコード１０２についての正確で完全なデバッグ情報を
発生することができない。これは、ソースコード１０２
の構造及び内容に関する情報の多くがソースコード１０
２から中間ソースコード１１０に翻訳する際に失われる
からである。 【０００８】それ故、コンパイラ１１４で発生されたコ
ンパイラデバッグ情報１２６では、ソースコード１０２
を効率良く且つ有効にデバッグするのに使用することが
できない。 【０００９】この問題を解決する従来の試みの１つに「
何もしない」という方法があった。この従来の解決法で
は、デバッグ１２２がコンパイラ１１４により発生され
たコンパイラデバッグ情報１２４を読取り、本来の変数
名や関数名を復元しようとしたり、発見的方法を使用し
てソースコード中の元来のデータ構造などを大まかに再
現しようとしたりする。 【００１０】しかし、この従来の方法では、デバッガ１
２２が元来のソースコード１０２を表示することができ
たとしても、デバッガ１２２の診断出力はどんなに良く
ても不完全で、多くの場合理解できない。また、ほとん
どの場合、ユーザは、変数及び関数を検査するためには
、中間コード中にある「変換された」変数名や関数名を
デバッガ１２２に対して手操作で指定しなければならな
かった。 【００１１】この問題を解決する従来の他の試みには「
後退法」という方法があった。この従来の解法では、デ
バッグ情報１２６を、元来のソースコード１０２の元来
のデータ構造などを再構成するように変換する試みがな
された。この修正されたデバッグ情報は、次にデバッガ
１２２に提示された。 【００１２】しかし、この従来の方法では、修正された
デバッグ情報は、中間ソースコード１１０からソースコ
ード１０２を再構成することが必らずしも可能ではない
ため、不完全で恐らくは不正でさえある。 【００１３】 【発明の目的】本発明は、トランスレータベースのソフ
トウェアコンパイルシステムで意味のあるシンボリック
デバッグ情報を発生することを目的とする。 【００１４】 【発明の概要】本発明の一実施例においては、図２及び
図３に図示するように、また以下に詳細に説明するよう
に、従来の解法に固有の問題点を、コンパイラ１１４及
び修正されたトランスレータ３０２に各々がそれぞれデ
バック情報１２６及び３０６を適宜発生させることによ
り解決している。デバッグ情報１２６及び３０６はマー
ジャ３１２を革新的に使用して組合わされる。得られる
ところの最終デバッグ情報を含むオブジェクトコード３
１６には完全且つ正確なデバッグ情報が入っている。オ
ブジェクトコード３１６に入っている最終デバッグ情報
は、元来のソースコード１０２を完全且つ正確に記述す
る。 【００１５】オブジェクトコード３１６にこの最終デバ
ッグ情報が入り、リンカ１２８により作製される実行可
能ファイル３５０に導入されることにより、修正された
デバッガ３２０は元来のソースコード１０２を完全且つ
正確に表示することができ、変数及び関数を用いて作業
するとき（元のソースコード１０２中の）実際の変数名
及び関数名を効率良く且つ効果的に使用することができ
る。また、このデバッグ情報があるため、デバッガ３２
０は、オーバーロード機能、インヘリタンス及びカプセ
ル化のような概念を取扱うことができる。 【００１６】 【実施例】本発明のこれらの及び他の利点及び特徴、更
には本発明がそれらを如何にして実現しているかは、種
々な実施例に関する以下の詳細な説明及び特許請求の範
囲から解るだろう。 【００１７】まず、以下の実施例の説明の目次を示す。 １．０．　概観 ２．０．　トランスレータ ３．０．　マージャ ３．１．　入力オブジェクトファイルのインターフェー
ス ３．１．１．　中核オブジェクトファイルクラス３．１
．２．　特殊化クラス ３．２．　デバッグ情報マニピュレータ３．２．１．　
ステップ８０２−ルックアップテーブルを構成 ３．２．２．　ステップ８０６−ルックアップテーブル
に合せる ３．２．３．　ステップ８１０−固定 ３．２．４．　ステップ８１４−整頓する３．３．　出
力オブジェクトファイルのインターフェース ４．０．　デバッガ 【００１８】１．０．　概観 図３は、本発明２２８のトランスレータベースのコンパ
イルシステムの構造図／機能フローチャートを示す。図
３で、長方形はソフトウェアモジュール／プロセスを表
わし、長円形はソフトウェアモジュール／プロセスの入
力及び出力を表わしている。 【００１９】図３に示すように、本発明の一実施例２２
８は、従来の解法に固有の問題点を、コンパイラ１１４
及び修正されたトランスレータ３０２に、各々がそれぞ
れコンパイラデバッグ情報１２６及びトランスレータデ
バッグ情報３０６を適宜発生させることにより解決して
いる。コンパイラデバッグ情報１２６及びトランスレー
タデバッグ３０６は、マージャ３１２を革新的に使用し
て組合わされる。得られるオブジェクトコード３１６に
は完全且つ正確な最終デバッグ情報が入っている。この
デバッグ情報は元来のソースコード１０２を完全且つ正
確に記述している。 【００２０】下に詳細に説明する通り、オブジェクトコ
ード３１６中に最終デバッグ情報が入っていることによ
り、修正されたデバッガ３２０は元来のソースコード１
０２を表示することができ、変数及び関数を用いて作業
するとき（元来のソースコード１０２中の）実際の変数
名及び関数名を使用することができる。また、この最終
デバッグ情報があるため、デバッガ３２０は、オーバー
ロード機能、インヘリタンス及びカプセル化のような概
念を取扱うことができる。 【００２１】図２に示すように、本発明のトランスレー
タベースのコンパイルシステムは、コンピュータプラッ
トフォーム２０２で動作するアプリケーションコンピュ
ータプログラム２２８である。コンピュータプラットフ
ォーム２０２は、中央処理装置（ＣＰＵ）２１２、ラン
ダムアクセスメモリ（ＲＡＭ）２１０及び入出力インタ
ーフェース２１４を含むハードウェアユニット２０８を
有している。コンピュータプラットフォーム２０２はオ
ペレーティングシステムを含んでおり、マイクロ命令コ
ード２０６を含んでいる場合もある。端末２１８、デー
タストレージ２２２及びプリンタ２２６のような種々の
周辺構成要素をコンピュータプラットフォーム２０２に
接続することができる。 【００２２】本発明の好適実施例では、コンピュータプ
ラットフォーム２０２は、ＨＰ９０００シリーズ３００
、６００、または８００コンピュータプラットフォーム
であり、ここで走っているオペレーティングシステム２
０４は、ＨＰ−ＵＸバージョン７．０である。また、本
発明の一実施例にかかるトランスレータベースのコンパ
イルシステム２２８は好適にはＣ＋＋言語で書かれてい
る。 【００２３】ＨＰ９０００シリーズの６００及び８００
コンピュータプラットフォームは、実質上同じである。 それ故、ここでＨＰ９０００シリーズ８００コンピュー
タプラットフォームというときはＨＰ９０００シリーズ
の６００及び８００の２つのコンピュータプラットフォ
ームを指すことを理解しなければならない。 【００２４】図３に示すように、本発明の一実施例のト
ランスレータベースのコンパイルシステム２２８は、修
正されたトランスレータ３０２、コンパイラ１１４、革
新的なマージャ３１２、リンカ１２８及び修正されたデ
バッガ３２０を含んでいる。 【００２５】本発明２２８の動作を図３を参照して全般
的に説明する。 【００２６】トランスレータ３０２は、入力としてソー
スコード１０２を受取る。ソースコードは、Ｃ＋＋のよ
うな高レベルのプログラム言語で書くことができる。ト
ランスレータ３０２は、ソースコード１０２の中間変形
体を発生する。ソースコード１０２の中間変形体は中間
ソースコード１１０と呼ばれ、Ｃのようなコンピュータ
プログラム言語で書かれていてよい。 【００２７】トランスレータ３０２はトランスレータデ
バッグ情報３０６も発生する。コンパイラデバッグ情報
１１８（以下に説明する）とは異なり、トランスレータ
デバッグ情報３０６はソースコードの構造及び内容を正
確に反映している。しかし、トランスレータデバッグ情
報３０６は、トランスレータ３０２がメモリの割当やコ
ード生成のような機械特有の事項に関するコンパイラの
判断の知識を持合せていないので、不完全である。 【００２８】コンパイラ１１４は、中間ソースコード１
１０を受取り、ソースコード１０２に対するオブジェク
トコード１２４を発生する。コンパイラ１１４はコンパ
イラデバッグ情報１２６も発生する。オブジェクトコー
ド１２４及びデバッグ情報１２６は、オブジェクトコー
ドファイル１１８に格納される。 【００２９】トランスレータ３０２と異なり、コンパイ
ラ１１４はメモリの割当やコードの生成のような機械特
有の事項に関するコンパイラの判断の知識を持っている
。それ故、コンパイラデバッグ情報１２６は、この点で
は欠けていない。しかし、上に述べたように、コンパイ
ラデバッグ情報１２６はなお、ソースコード１０２の構
造及び内容を完全且つ正確に表わしていない。 【００３０】マージャ３１２は、オブジェクトコードフ
ァイル１１８とトランスレータデバッグ情報３０６を受
け取る。上述の通り、コンパイラデバッグ情報１２６及
びトランスレータデバッグ情報３０６はそれぞれある領
域を欠いている。しかし、これらの領域は重なっていな
い。それ故、マージ３１２はコンパイラデバッグ情報１
２６及びトランスレータデバッグ情報３０６に入ってい
る情報を組合せて最終デバッグ情報を作製する。マージ
ャ３１２は、最終デバッグ情報をコンパイラ１１４が発
生したオブジェクトコード１１８と組合せて、最終デバ
ッグ情報を含むオブジェクトコード３１６を作製する。 【００３１】最終デバッグ情報は元来のソースコード１
０２を完全且つ正確に表わしている。 【００３２】リンカ１２８は、最終デバッグ情報を含む
オブジェクトコード３１６を他のオブジェクトコードフ
ァイル１３４とリンクする。リンカ１２８は、最終デバ
ッグ情報が入っている実行可能ファイル３５０を作製す
る。 【００３３】デバッガ３２０は、最終デバッグ情報が入
っている実行可能ファイル３５０を入力として受取る。 ユーザ（図３には示してない）の監督のもとに、デバッ
ガ３２０は最終デバッグ情報を使用して元来のソースコ
ード１０２を表示し、変数及び関数を用いて作業すると
きは（元来のソースコード１０２中の）実際の変数名及
び関数名を使用する。また、デバッガ３２０は、最終デ
バッグ情報を使用してオーバーロード機能、インヘリタ
ンス及びカプセル化のような概念を取扱う。 【００３４】本発明の一実施例のシステム２２８のデバ
ッガ３２０は、それが最終デバッグ情報中に埋め込まれ
たトランスレータデバッグ情報を利用するという特徴を
備えているという点で従来のデバッガ１２２の修正され
たものである。 【００３５】本発明の好適実施例では、ソースコード１
０２はＣ＋＋言語で書かれており、中間ソースコード１
１０はＣ言語で書かれている。 【００３６】しかし、本発明は、どんなトランスレータ
ベース環境でも働くようにされており、またそのように
意図されている。従って、本発明の範囲は、Ｃ＋＋／Ｃ
言語に限定されない。 【００３７】Ｃ＋＋言語は当業者には周知の事項である
が、その一般的説明が必要ならば、Ｍａｒｇａｒｅｔ　
Ｅｌｌｉｓ及びＢｊａｒｎｅ　Ｓｔｒｏｕｓｔｒｕｐ　
著「Ａｎｎｏｔａｔｅｄ　Ｃ＋＋　Ｒｅｆｅｒｅｎｃｅ
　Ｍａｎｕａｌ　（注訳付きＣ＋＋便覧）」（Ａｄｄｉ
ｓｏｎ　Ｗｅｓｌｅｙ　１９９０）を参照されたい。Ｃ
言語も周知な事項であるが、一般的説明が必要ならば、
Ａｍｅｒｉｃａｎ　Ｎａｔｉｏｎａｌ　Ｓｔａｎｄａｒ
ｄ　ｆｏｒ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｓｙｓｔｅｍｓ
−Ｐｒｏｇｒａｍｍｉｎｇ　Ｌａｎｇｕａｇｅ　Ｃ（情
報システムに関するアメリカ国家規格−プログラム言語
Ｃ）（文書番号Ｘ３Ｊ１１／９０−０１３）を参照され
たい。 【００３８】次の各章では本発明２２８のトランスレー
タベースのコンパイルシステムのシステムについて一層
詳細に説明する。 【００３９】コンパイラ１１４のような、本発明２２８
の或る局面は、既存のコンパイラ、トランスレータ、リ
ンカ及びデバッガの技術を用いて実現することができる
。しかし、既存のトランスレータ及びデバッガの技術に
修正を加えることは、本発明の改善を達成するのに必要
である。以下の各章での説明は、既存のトランスレータ
及びデバッガの技術（及び革新的なマージャ３１２）に
加えられるこれら修正に重点を置く。既存のコンパイラ
、リンカ、トランスレータ及びデバッガの技術も当業者
には周知名者であるが、その一般的説明については、Ａ
ｌｆｒｅｄ　Ｖ．Ａｈｏ、Ｒａｖｉ　Ｓｅｔｈｉ及びＪ
ｅｆｆｒｅｙ　Ｄ．Ｕｌｌｍａｎ著「Ｃｏｍｐｉｌｅｒ
ｓ，　Ｐｒｉｎｃｉｏｌｅｓ，　Ｔｅｃｈｎｉｑｕｅｓ
，　ａｎｄ　Ｔｏｏｌｓ（コンパイラ、原理、手法及び
ツール）」（Ａｄｄｉｓｏｎ　Ｗｅｓｌｅｙ　１９８６
）を参照されたい。 【００４０】２．０　トランスレータ 図４は、本発明２２８のトランスレータ３０２の構造図
／フローチャートを示す。図４で、長方形はソフトウェ
アモジュール／プロセスを表わし、長円形はソフトウェ
アモジュール／プロセスの入力及び出力を表わす。 【００４１】図４に示す通り、本発明のシステム２２８
のトランスレータ３０２は、スキャナ／パーザ４０２、
デバッグ情報生成部４１０及びコード生成部４１８を含
んでいる。 【００４２】スキャナ／パーザ４０２は、Ｃ＋＋のよう
な高レベルプログラム言語で書くことができるソースコ
ード１０２を受取り、ソースコード１０２を表わす意味
情報を含む内部データ構造（意味情報／内部データ構造
４０６）を構築する。デバッグ情報生成部４１０は、意
味情報含む内部データ構造、つまり意味情報／内部デー
タ構造４０６を受取り、トランスレータデバッグ情報３
０６を生成する。 【００４３】コード生成部４１８はまた意味情報／内部
データ構造４０６を受取って中間ソースコード１１０を
発生する。中間ソースコード１１０はＣ言語で書かれて
いてよい。 【００４４】トランスレータ３０２に含まれているデバ
ッグ情報生成部４１０は、コンパイラ１１４に含まれて
いるデバッグ情報生成部（図示せず）と非常に良く似た
動作をする。従って、デバッグ情報生成部４１０の構造
及び動作の一般的説明は、上に引用したＡｌｆｒｅｄ　
Ｖ．Ａｈｏ、Ｒａｖｉ　Ｓｅｔｈｉ及びＪｅｆｆｅｒｙ
　Ｄ．Ｕｌｌｍａｎ著「Ｃｏｍｐｉｌｅｒｓ，　Ｐｒｉ
ｎｃｉｐｌｅｓ，　Ｔｅｃｈｎｉｑｕｅｓ，　ａｎｄ　
Ｔｏｏｌｓ」に書いてある。 【００４５】トランスレータ３０２に含まれているデバ
ッグ情報生成部４１０とコンパイラ１１４に含まれてい
るデバッグ情報生成部の主な相違は、デバッグ情報生成
部４１０はトランスレータ３０２に含まれているので、
ソースコード１０２の構造及び内容を知っているという
ことである。それ故、デバッグ情報生成部４１０により
発生されるトランスレータデバッグ情報３０６は、ソー
スコード１０２の構造及び内容を正確且つ完全に反映し
ている。 【００４６】しかし、トランスレータ３０２に含まれて
いるデバッグ情報生成部４１０は、マシンアーキテクチ
ャ及びマシンアドレス（関数及び変数のアドレスを含む
）を取扱う情報を知っていない。それ故、デバッグ情報
生成部４１０により発生されるトランスレータデバッグ
情報３０６は、マシンアーキテクチャ及びマシンアドレ
スの情報を欠いている。トランスレータデバッグ情報３
０６に欠けている特定の局面について下に詳細に説明す
る。 【００４７】３．０　マージャ マージャ３１２は、トランスレータ３０２が作製したシ
ンボリックデバッグ情報３０６をコンパイラ１１４が作
製したコンパイラデバッグ情報１２６（及びオブジェク
トコード１２４）と組合せる。 【００４８】図５は、マージャ３１２の構造図／機能フ
ローチャートを示す。図５で、長方形はソフトウェアモ
ジュール／プロセスを表わし、長円形はソフトウェアモ
ジュール／プロセスの入力及び出力を表わしている。 【００４９】図５に示す通り、マージャ３１２は、入力
オブジェクトファイルインターフェース５０２、５０４
、デバッグ情報マニピュレータ５１０及び出力オブジェ
クトファイルインターフェース５１４を含んでいる。 一般に、入力オブジェクトファイルインターフェース５
０２は、オブジェクトコードファイル１１８から読出し
を行ってコンパイラデバッグデータ構造５１６を生成す
る。入力オブジェクトファイルインターフェース５０４
は、トランスレータデバッグ情報３０６から読出しを行
ってトランスレータデバッグデータ構造５１８を生成す
る。デバッグ情報マニピュレータ５１０は、デバッグデ
ータ構造５１６、５１８に入っている情報を組合せてマ
ージ済みルックアップテーブル５２８及びポータブル出
力決定用情報（ｐｏｒｔａｂｌｅ　ｉｎｐｕｔ　ｆｉｘ
ｕｐ）５３０を出力する。出力オブジェクトファイルイ
ンターフェース５１４は最終デバッグ情報を含むオブジ
ェクトコード３１６に対する書込みを行う。 【００５０】マージャ３１２の機能フローチャートを図
６に示す。マージャ３１２の動作を図５及び図６を参照
して下に説明する。 【００５１】ステップ６０２と６０６で、入力オブジェ
クトファイルインターフェース５０２、５０４はオブジ
ェクトコードファイル１１８とトランスレータデバッグ
情報ファイル３０６をオープンし、デバッグ情報をこれ
らのファイル１１８、３０６から読出す。入力オブジェ
クトファイルインターフェース５０２、５０４は、デバ
ッグ情報をデバッグデータ構造５１６、５１８に置く。 ここに置かれた情報はデバッグ情報マニピュレータ５１
０に渡される。 【００５２】ステップ６１０で、デバッグ情報マニピュ
レータ５１０は、コンパイラデバッグデータ構造５１６
とトランスレータデバッグデータ構造５１８を比較し、
レコードをコンパイラデバッグデータ構造５１６からト
ランスレータデバッグデータ構造５１８の対応するレコ
ードにコピーする。更新されたトランスレータデバッグ
データ構造はマージ済みルックアップテーブル５２８に
格納される。 【００５３】ステップ６１４で、出力オブジェクトファ
イルインターフェース５１４は、オブジェクトコード１
２４及びマージ済みルックアップテーブル５２８からの
情報を新たな最終デバッグ情報を含むオブジェクトコー
ド３１６にコピーする。 【００５４】入力オブジェクトファイルインターフェー
ス５０２、５０４、デバッグ情報マニピュレータ５１０
及び出力オブジェクトファイルインターフェース５１４
について次の章で一層詳細に説明する。 【００５５】３．１　入力オブジェクトファイルインタ
ーフェース図５に示すように、入力オブジェクトファイ
ルインターフェース５０２及び５０４は、入力としてそ
れぞれオブジェクトコードファイル１１８及びトランス
レータデバッグ情報３０６を受取る。 【００５６】オブジェクトコードファイル１１８のコン
パイラデバッグ情報１２６は、コンパイラからのデバッ
グ用名前及び型テーブル（すなわち、グローバルな名前
及び型テーブル（Ｇｌｏｂａｌ　Ｎａｍｅ　ａｎｄ　Ｔ
ｙｐｅ　Ｔａｌｂｅ、ＧＮＴＴ）及びローカルな名前及
び型テーブル（Ｌｏｃａｌ　Ｎａｍｅ　ａｎｄ　Ｔｙｐ
ｅ　Ｔａｂｌｅ、ＬＮＴＴ）等の各種情報を含んでいる
。コンパイラデバッグ情報１２６は、コンパイラからの
値テーブル（ＶＴ）も含んでいるが、これは実質的には
名前ストリングのテーブルである。コンパイラデバッグ
情報１２６はまた、コンパイラ１１４のオブジェクトコ
ード１２４のソース行テーブル（ＳＬＴ）を含んでいる
。コンパイラデバッグ情報１２６はまた決定用情報リス
ト（ｆｉｘｕｐ　ｌｉｓｔ）を含んでいるが、これはリ
ンカ１２８がコンパイラ１１４のオブジェクトコード１
２４を決定、設定するのに必要とする情報を含んでいる
。オブジェクトファイル１１８は、オブジェクトファイ
ルシンボルテーブルを含んでいる。このシンボルテーブ
ルは各種識別子（すなわち、シンボル）の名前及びアド
レスを含んでいる。これらのシンボルは決定用情報リス
ト中で参照される。 【００５７】コンパイラデバッグ情報１２４と同様、ト
ランスレータデバッグ情報３０６は、トランスレータか
らのデバッグ用名前及び型テーブルとトランスレータか
らの値テーブル（ＴＶ）を含んでいる。トランスレータ
デバッグ情報３０６はソース行テーブル（ＳＬＴ）や決
定用情報リストを含んでいない。それは、トランスレー
タ３０２がそのような情報を発生しないからである。 【００５８】入力オブジェクトファイルインターフェー
ス５０２は、コンパイラデバッグ情報１２６を読出し、
それをコンパイラデバッグデータ構造５１６に置く。同
様に、入力オブジェクトファイルインターフェース５０
４は、トランスレータデバッグ情報３０６を読出してそ
れをトランスレータデバッグデータ構造５１８に置く。 図５に示すように、コンパイラ及びトランスレータデバ
ッグデータ構造５１６、５１８はデバッグ情報マニピュ
レータ５１０への入力である。 【００５９】コンパイラデバッグデータ構造５１６とト
ランスレータデバッグデータ構造５１８は同じフォーマ
ットを共有している。この共通のフォーマットを表１に
示す。 【００６０】 〈表−１〉 ｓｔｒｕｃｔ　ｄｅｂｕｇｉｎｆｏ　｛ｃｈａｒ　＊ｈ
ｅａｄｅｒ；　　／／　各種デバッグ情報要素ｉｎｔ　
　　ｈｅａｄｅｒ＿ｌｅｎ； ｃｈａｒ　＊ｇｎｔｔ； ｉｎｔ　　　ｇｎｔｔ＿ｌｅｎ； ｃｈａｒ　＊ｌｎｔｔ； ｉｎｔ　　　ｌｎｔｔ＿ｌｅｎ； ｃｈａｒ　＊ｓｌｔ； ｉｎｔ　　　ｓｌｔ＿ｌｅｎ； ｃｈａｒ　＊ｖｔ； ｉｎｔ　　　ｖｔ＿ｌｅｎ； ｄｔａｂ　＊ｇｔｂｌ；　／／　早見参照中間テーブル
ｄｔａｂ　＊ｌｔｂｌｅ； ｏｌｄｆｉｘｕｐｌｉｓｔ　＊ｏｌｄｇｆｘｕｐ；　／
／　古い決定情報リスト　（ｇｎｔｔ，　ｌｎｔｔ） ｏｌｄｆｉｘｕｐｌｉｓｔ　＊ｏｌｄｌｆｘｕｐ；ｎｅ
ｗｆｉｘｕｐｌｉｓｔ　＊ｇｆｘｕｐ；　／／　新しい
決定情報リスト　（ｇｎｔｔ，　ｌｎｔｔ） ｎｅｗｆｉｘｕｐｌｉｓｔ　＊ｌｆｘｕｐ；｝； 【００６１】入力オブジェクトファイルインターフェー
ス５０２及び入力オブジェクトファイルインターフェー
ス５０４は、本質的に同じ様に動作する。しかし、多少
の些細な相違がある。このような相違はその入力が相違
していることを反映している。例えば、入力オブジェク
トファイルインターフェース５０２は、オブジェクトコ
ード１２４中の名前がソースコード１０２中の名前と一
致するように名前を復元するソフトウェアルーチンを含
んでいる。 【００６２】本発明２２８の好適実施例では、入力オブ
ジェクトファイルインターフェース５０２、５０４（及
び出力オブジェクトファイルインターフェース５１４も
）は、クラスとして実現されている。これらクラスのイ
ンスタンスはオブジェクトコード及びデバッグ情報が入
っているファイルを読み書きするのに使用される。 【００６３】これらのクラスは２つの層に分けられる。 これらの層とは、基底クラス（ＢａｓｅＣｌａｓｓ）を
表わす中核オブジェクトファイルクラス（Ｃｏｒｅ　Ｏ
ｂｊｅｃｔ　Ｆｉｌｅ　Ｃｌａｓｓｅｓ）と、中核オブ
ジェクトファイル基底クラスから誘導されたクラスを表
わす特殊化クラス（Ｓｐｅｃｉａｌｉｚｅｄ　Ｃｌａｓ
ｓｅｓ）である。これらクラスについて次の章で説明す
る。 【００６４】３．１．１　中核オブジェクトファイルク
ラス 中核オブジェクトファイルクラスは、オブジェクトファ
イルヘッダやシンボルテーブルのような共通なオブジェ
クトファイルデータ構造を読出すのに使用される。中核
オブジェクトファイルクラスは、シンボルテーブル内の
シンボルを参照するアクセスルーチン及び初期設定ポイ
ンタを参照するアクセスルーチンを含む。中核オブジェ
クトファイルクラスはオブジェクトファイルを読み書き
するジェネリックルーチンもある。 【００６５】本発明の好適実施例２２８では、２つの中
核オブジェクトファイルクラス、ｓｏｍ３００とｓｏｍ
８００、がある。ｓｏｍ３００はＨＰ９０００シリーズ
３００コンピュータプラットフォーム２０２　で動作し
、ｓｏｍ８００はＨＰ９０００シリーズの６００及び８
００コンピュータプラットフォーム２０２で動作する。 ｓｏｍ３００及びｓｏｍ８００について次章で説明する
。 【００６６】３．１．１．１　クラスｓｏｍ３００クラ
スｓｏｍ３００という抽象概念の主な目的は、オブジェ
クト／デバッグファイル１１８、３０６、３１６に対す
る効率的且つユーザから分かりやすいインターフェース
を提供することである。クラスｓｏｍ３００を構成する
コンピュータプログラムセグメントを表２に示す。 【００６７】 　　　　　　　　　〈表−２〉 ｃｌａｓｓ　ｃｏｆｆｈｅａｄｅｒ　：　ｐｕｂｌｉｃ
　ｅｘｅｃ　｛　　ｐｕｂｌｉｃ： 　　　　ｃｏｆｆｈｅａｄｅｒ（）　｛｝　　　　ｃｏ
ｆｆｈｅａｄｅｒ（ｆｓｔｒｅａｍ＆）；　　　　ｃｏ
ｆｆｈｅａｄｅｒ（ｃｏｆｆｈｅａｄｅｒ＆　ｏｔｈｅ
ｒ）　｛＊ｔｈｉｓ　＝　ｏｔｈｅｒ；｝　　　　ｉｎ
ｔ　ｖａｌｉｄａｔｅ（）；｝； ｃｌａｓｓ　ｓｙｍｅｎｔ３００　：　ｐｕｂｌｉｃ　
ｎｌｉｓｔ＿　｛　　ｐｕｂｌｉｃ： 　　　　ｓｙｍｅｎｔ３００（）　｛ｎａｍｅ　＝　Ｎ
ＵＬＬ；｝；　　　　■ｓｙｍｅｎｔ３００（）； 　　　　ｃｈａｒ　＊ｎａｍｅ； 　　　　ｉｎｔ　ｃｏｐｙ（ｃｈａｒ　＊ｐｔｒ）；　
　　　ｉｎｔ　ｓｙｍｓｉｚ（）　｛ｒｅｔｕｒｎ　（
　　　　ｓｉｚｅｏｆ（ｌｏｎｇ）　＋　　　　　　　
　　　　　　　　　　　　　　　　　　　２　＊　ｓｉ
ｚｅｏｆ（ｃｈａｒ）　＋　　　　　　　　　　　　　
　　　　　　　　　　　　　２　＊　ｓｉｚｅｏｆ（ｓ
ｈｏｒｔ）　＋　　　　　　　　　　　　　　　　　　
　　　　　　　　ｎ＿ｌｅｎｇｔｈ）；｝　　　　ｓｙ
ｍｅｎｔ３００＆　ｏｐｅｒａｔｏｒ　＝　（ｓｙｍｅ
ｎｔ３００＆　ｏｔｈｅｒ）；　　　　ｆｒｉｅｎｄ　
ｉｎｔ　ｄｉｇｅｓｔ（ｃｈａｒ　＊，　ｌｏｎｇ，　
ｓｙｍｅｎｔ３００　＊＆）；｝； ｃｌａｓｓ　ｓｏｍ３００　｛ 　　ｐｒｏｔｅｃｔｅｄ： 　　　　ｃｈａｒ　　　　　　　　ｏｐｅｎ；　　　　
　　　　　　　／／　このｓｏｍはオープンしているか
？　　　　ｃｈａｒ　　　　　　　　ｖａｌｉｄ；　　
　　　　　　　　／／　このｓｏｍは正しいか？　　　
　ｃｏｆｆｈｅａｄｅｒ　＊ｈｅａｄｅｒ＿ｐｔｒ；　
　　　　／／　オブジェクトファイルヘッダへの　　　
　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　／／　ポインタ　　　　ｓｙｍｅｎｔ３００　
　＊ｓｙｍ；　　　　　　　　　　　　／／　シンボル
テーブルへのポインタ　　　　ｉｎｔ　　　　　　　　
　ｓｙｍ＿ｃｏｕｎｔ；　　　　　　／／　シンボル数
　　　　ｌｏｎｇ　　　　　　　　ｓｔａｒｔ＿ｏｆ＿
ｄａｔａ；　　／／　オブジェクトファイル中での　　
　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　／／　初期化されたデータのオフセット　　
　　ｆｓｔｒｅａｍ　　　　＊ｓｏｍｆｉｌｅ；　　　
　　　　　／／　入出力のためにオープンしている　　
　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　／／　ファイルのポインタ　　ｐｕｂｌｉｃ
： 　　　　／／　コンストラクタ及びデストラクタ　　　
　　　　　　　　　　　　　ｓｏｍ３００（）；　　　
　　　　　　　　　　　　　ｓｏｍ３００（ｃｈａｒ　
＊ｆｉｌｅｎａｍｅ，　ｉｎｔ　ｍｏｄｅ＝ｉｓｏ：：
ｉｎ）；　　　　　　　　　　　　　　　　　　／／　
ファイル名で初期化　　　　　　　　　　　　　　　　
■ｓｏｍ３００（）；　　　　／／　手短に正当性をチ
ェックするルーチン　　　　　　　　　　　　　　　　
ｏｐｅｒａｔｏｒ　ｉｎｔ（）　｛ｒｅｔｕｒｎ　ｖａ
ｌｉｄ；｝　　　　／／　パッケージされた入出力アク
セスルーチン　　　　／／　これらのルーチンはｆｓｔ
ｒｅａｍ中の対応するルーチンと　　　　／／　　　同
じ機能を果す 　　　　ｓｔｒｅａｍｐｏｓ　　　ｔｅｌｌｇ　（）　
　　　　　　　　　　　　　　　｛ 　　　　　　　　　　　　　　　　　　　　ｒｅｔｕｒ
ｎ　ｓｏｍｆｉｌｅ−＞ｔｅｌｌｇ（）；　　　　　　
　　　　　　　　　　｝ 　　　　ｉｓｔｒｅａｍ＆　　　　ｓｅｅｋｇ　（ｓｔ
ｒｅａｍｏｆｆ　ｓｏ，　ｓｅｅｋ＿ｄｉｒ　ｄｓ）；
　　　　　　　　　　　　　　　　｛ 　　　　　　　　　　　　　　　　　　　　ｒｅｔｕｒ
ｎ　ｓｏｍｆｉｌｅ−＞ｓｅｅｋｇ（ｓｏ，　ｓｄ）；
　　　　　　　　　　　　　　　　｝ 　　　　ｉｓｔｒｅａｍ＆　　　　ｒｅａｄ　（ｃｈａ
ｒ　＊ｓ，　ｌｏｎｇ　ｎ）　　　　　　　　　　　　
　　　　｛ 　　　　　　　　　　　　　　　　　　　　ｒｅｔｕｒ
ｎ　ｓｏｍｆｉｌｅ−＞ｒｅａｄ（ｓ，　（ｉｎｔ）　
ｎ）；　　　　　　　　　　　　　　　　｝ 　　　　ｓｔｒｅａｍｐｏｓ　　　ｔｅｌｌｐ　（）　
　　　　　　　　　　　　　　　｛ 　　　　　　　　　　　　　　　　　　　　ｒｅｔｕｒ
ｎ　ｓｏｍｆｉｌｅ−＞ｔｅｌｌｐ（）；　　　　　　
　　　　　　　　　　｝ 　　　　ｏｓｔｒｅａｍ＆　　　　ｓｅｅｋｐ　（ｓｔ
ｒｅａｍｏｆｆ　ｓｏ，　ｓｅｅｋ＿ｄｉｒ　ｓｄ）　
　　　　　　　　　　　　　　　｛ 　　　　　　　　　　　　　　　　　　　　ｒｅｔｕｒ
ｎ　ｓｏｍｆｉｌｅ−＞ｓｅｅｋｐ（ｓｏ，　ｓｄ）；
　　　　　　　　　　　　　　　　｝ 　　　　ｏｓｔｒｅａｍ＆　　　　ｗｒｉｔｅ　（ｃｈ
ａｒ　＊ｓ，　ｌｏｎｇ　ｎ）　　　　　　　　　　　
　　　　　｛ 　　　　　　　　　　　　　　　　　　　　ｒｅｔｕｒ
ｎ　ｓｏｍｆｉｌｅ−＞ｗｒｉｔｅ（ｓ，　（ｉｎｔ）
　ｎ）；　　　　　　　　　　　　　　　　｝ 　　　　／／　シンボルテーブルアクセスルーチン　　
　　ｉｎｔ　　　　　　　　　ｎｕｍ＿ｓｙｍｂｏｌｓ
（）　｛ｒｅｔｕｒｎ　ｓｙｍ＿ｃｏｕｎｔ；｝　　　
　ｓｙｍｅｎｔ３００　　＊ｇｅｔ＿ｓｙｍｂｏｌｓ（
）　｛ｒｅｔｕｒｎ　ｓｙｍ；｝　　　　ｓｙｍｅｎｔ
３００　　＊ｆｉｎｄ＿ｓｙｍｂｏｌ（ｃｈａｒ　＊）
；　　　　ｃｈａｒ　　　　　　　＊ｓｙｍ＿ｎａｍｅ
　（ｓｙｍｅｎｔ３００＆　ｓ）；　　　　　　　　　
　　　　　　　｛ 　　　　　　　　　　　　　　　　　　　　ｒｅｔｕｒ
ｎ　ｓ．ｎａｍｅ；　　　　　　　　　　　　　　　　
｝ 　　　　ｌｏｎｇ　　　　　　　　ｓｙｍ＿ｌｏｃ　（
ｓｙｍｅｎｔ３００＆　ｓ）；　／／　ファイル中でｓ
ｙｍが　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　／／　指
している位置　　　　ｌｏｎｇ　　　　　　　　ｓｙｍ
＿ｖａｌ　（ｓｙｍｅｎｔ３００＆　ｓ）；　／／　ロ
ードされたプログ　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　
　／／　ラム中でｓｙｍが　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　／／　指している位置 【００６８】ｓｙｍ＿ｌｏｃ（）関数は、オブジェクト
／デバッグファイル１１８、３０６中でシンボルの初期
設定値を格納しているロケーションを返す。ｓｙｍ＿ｌ
ｏｃ（）関数は初期設定ポインタにパッチを当てるのに
使用される。 【００６９】ｓｙｍ＿ｖａｌ（）関数は、コンピュータ
プログラムをＲＡＭ２１０にロードされた時のシンボル
の実行時アドレスを返す。 【００７０】ｃｏｆｆｈｅａｄｅｒクラスは、コンスト
ラクタ及び検査子関数を付加するために、ヘッダを包む
のに主に使用される。 【００７１】ｃｙｍｅｎｔ３００クラスは重要である。 ＨＰ９０００シリーズ３００コンピュータプラットフォ
ーム２０２で作られたオブジェクトコードファイル１１
８の中のシンボルの通常の表現は、クランチ（ｃｒｕｎ
ｃｈ）されたレコード（ｓｔｒｕｃｔ　ｎｌｉｓｔ＿）
の後ろに、当該シンボル名をナルコードで終端しないと
きの正確なバイト長を示す数が付けられたものである。 【００７２】従って、その最初の動作として、コンスト
ラクタｓｏｍ３００（）は、シンボルテーブル全体を読
取り、シンボルテーブルをもっと使いやすい形に、具体
的にはｓｙｍｅｎｔ３００レコードの配列に変換する。 ｓｙｍｅｎｔ３００の配列には２つの長所がある。 １．大きさが一定のレコードの配列であるから、走査（
ｔｒａｖｅｒｓｅ）し易い。 ２．名前は今やナルコードで終端され且つその先頭部分
への直接のポインタを含んでいるので取扱い易い。 【００７３】クラスｓｙｍｅｎｔ３００のｃｏｐｙ（）
関数は、加工前のシンボルテーブルからｓｙｍｅｎｔ３
００ノードを作り出すために、ｄｉｇｅｓｔ（）関数に
より使用される。演算子「＝」はこのようなノードのコ
ピーを容易にする。 【００７４】３．１．１．２　クラスｓｏｍ８００クラ
スｓｏｍ８００はクラスｓｏｍ３００より幾らか複雑で
ある（ＨＰ９０００シリーズ６００及び８００のオブジ
ェクトファイルのフォーマットが複雑であるため）。し
かし、クラスｓｏｍ８００はクラスｓｏｍ３００と実質
上同じ機能を果す。 【００７５】クラスｓｏｍ８００を構成するコンピュー
タプログラムセグメントを表３に示す。クラスｓｏｍ８
００に含まれているクラス、データ構造及び機能はクラ
スｓｏｍ３００にあるものと相似である。 【００７６】 　　　　　　　　　〈表−３〉 ｃｌａｓｓ　ｓｏｍｈｅａｄｅｒ　：　ｐｕｂｌｉｃ　
ｈｅａｄｅｒ　｛　　ｐｕｂｌｉｃ： 　　　　ｓｏｍｈｅａｄｅｒ（）　｛｝　　　　ｓｏｍ
ｈｅａｄｅｒ（ｆｓｔｒｅａｍ＆）；　　　　ｓｏｍｈ
ｅａｄｅｒ（ｓｏｍｈｅａｄｅｒ＆　ｏｔｈｅｒ）　｛
＊ｔｈｉｓ　＝　ｏｔｈｅｒ；｝　　　　ｉｎｔ　ｖａ
ｌｉｄａｔｅ（）；｝； ｃｌａｓｓ　ｓｏｍ８００　｛ 　　ｐｒｏｔｅｃｔｅｄ： 　　　　ｃｈａｒ　　　　　　　ｏｐｅｎ；　　　　　
　　　　　　／／　このｓｏｍはオープンしているか？
　　　　ｃｈａｒ　　　　　　　ｖａｌｉｄ；　　　　
　　　　　　／／　このｓｏｍは正しいか？　　　　ｓ
ｏｍｈｅａｄｅｒ　＊ｈｅａｄｅｒ＿ｐｔｒ；　　　　
　／／　オブジェクトファイルヘッダへの　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　
　　　／／　ポインタ　　　　ＳＰＡＨＤＲ　　　　＊
ｓｐａｃｅ＿ｄｉｃｔ；　　　　　／／　スペーステー
ブルへのポインタ　　　　ｉｎｔ　　　　　　　　ｓｐ
ａｃｅ＿ｃｏｕｎｔ；　　　　／／　スペースの数　　
　　ＳＣＮＨＤＲ　　　　＊ｓｕｂｓｐａｃｅ＿ｄｉｃ
ｔ；　　／／　サブスペーステーブルへのポインタ　　
　　ｉｎｔ　　　　　　　　ｓｕｂｓｐａｃｅ＿ｃｏｕ
ｎｔ；　／／　サブスペースの数　　　　ｃｈａｒ　　
　　　　＊ｓｐａｃｅ＿ｓｔｒｉｎｇｓ；　　／／　ス
ペース文字列テーブルへのポインタ　　　　ｉｎｔ　　
　　　　　　ｓｐａｃｅ＿ｓｔｒｉｎｇｓ＿ｓｉｚｅ；
　／／　その長さ　　　　ＳＹＭＥＮＴ　　　　＊ｓｙ
ｍ；　　　　　　　　　　　　／／　シンボルテーブル
へのポインタ　　　　ｉｎｔ　　　　　　　　ｓｙｍ＿
ｃｏｕｎｔ；　　　　　　／／　シンボルの数　　　　
ｃｈａｒ　　　　　　＊ｓｙｍｂｏｌ＿ｓｔｒｉｎｇｓ
；　／／　シンボル文字列テーブルへのポインタ　　　
　ｉｎｔ　　　　　　　　ｓｙｍｂｏｌ＿ｓｔｒｉｎｇ
ｓ＿ｓｉｚｅ；　／／　その長さ　　　　ＩＮＩＴＰＴ
Ｒ　　　　ｉｎｉｔ＿ｐｔｒｓ；　　　　　　／／　初
期化ポインタへのポインタ　　　　ｉｎｔ　　　　　　
　　ｉｎｉｔ＿ｐｔｒｓ＿ｃｏｕｎｔ；　　　　／／　
初期化ポインタの数　　　　ｆｓｔｒｅａｍ　　　＊ｓ
ｏｍｆｉｌｅ；　　　　　　　　／／　オープンしてい
るファイルのポインタ　　ｐｕｂｌｉｃ： 　　　　／／　コンストラクタ及びデストラクタ　　　
　ｓｏｍ８００（）； 　　　　ｓｏｍ８００（ｃｈａｒ　＊ｆｉｌｅｎａｍｅ
，　ｉｎｔ　ｍｏｄｅ＝ｉｏｓ：：ｉｎ）；　／／　フ
ァイル名で初期化　　　　■ｓｏｍ８００（）； 　　　　／／　手短な正当性チェッカ 　　　　　　　　　　　　　　　ｏｐｅｒａｔｏｒ　ｉ
ｎｔ（）　｛ｒｅｔｕｒｎ　ｖａｌｉｄ；｝　　　　／
／　パッケージされた入出力アクセスルーチン　　　　
／／　これらのルーチンはｆｓｔｒｅａｍ中の対応する
ルーチンと同じ機能を果す　　　　ｓｔｒｅａｍｐｏｓ
　　ｔｅｌｌｇ　（）　　　　　　　　　　　　　　　
｛ 　　　　　　　　　　　　　　　　　　　ｒｅｔｕｒｎ
　ｓｏｍｆｉｌｅ−＞ｔｅｌｌｇ（）；　　　　　　　
　　　　　　　　｝ 　　　　ｉｓｔｒｅａｍ＆　　　ｓｅｅｋｇ　（ｓｔｒ
ｅａｍｏｆｆ　ｓｏ，　ｓｅｅｋ＿ｄｉｒ　ｓｄ）　　
　　　　　　　　　　　　　｛ 　　　　　　　　　　　　　　　　　　　ｒｅｔｕｒｎ
　ｓｏｍｆｉｌｅ−＞ｓｅｅｋｇ（ｓｏ，　ｓｄ）；　
　　　　　　　　　　　　　　｝ 　　　　ｉｓｔｒｅａｍ＆　　　ｒｅａｄ　（ｃｈａｒ
　＊ｓ，　ｌｏｎｇ　ｎ）　　　　　　　　　　　　　
　　｛ 　　　　　　　　　　　　　　　　　　　ｒｅｔｕｒｎ
　ｓｏｍｆｉｌｅ−＞ｒｅａｄ（ｓ，　（ｉｎｔ）　ｎ
）；　　　　　　　　　　　　　　　｝ 　　　　ｓｔｒｅａｍｐｏｓ　　ｔｅｌｌｐ　（）　　
　　　　　　　　　　　　　｛ 　　　　　　　　　　　　　　　　　　　ｒｅｔｕｒｎ
　ｓｏｍｆｉｌｅ−＞ｔｅｌｌｐ（）；　　　　　　　
　　　　　　　　｝ 　　　　ｏｓｔｒｅａｍ＆　　　ｓｅｅｋｐ　（ｓｔｒ
ｅａｍｏｆｆ　ｓｏ，　ｓｅｅｋ＿ｄｉｒ　ｓｄ）　　
　　　　　　　　　　　　　｛ 　　　　　　　　　　　　　　　　　　　ｒｅｔｕｒｎ
　ｓｏｍｆｉｌｅ−＞ｓｅｅｋｐ（ｓｏ，　ｓｄ）；　
　　　　　　　　　　　　　　｝ 　　　　ｏｓｔｒｅａｍ＆　　　ｗｒｉｔｅ　（ｃｈａ
ｒ　＊ｓ，　ｌｏｎｇ　ｎ）　　　　　　　　　　　　
　　　｛ 　　　　　　　　　　　　　　　　　　　ｒｅｔｕｒｎ
　ｓｏｍｆｉｌｅ−＞ｗｒｉｔｅ（ｓ，　（ｉｎｔ）　
ｎ）；　　　　　　　　　　　　　　　｝ 　　　　／／　シンボルテーブルアクセスルーチン　　
　　ｉｎｔ　　　　　　　　ｎｕｍ＿ｓｐａｃｅｓ（）
　｛ｒｅｔｕｒｎ　ｓｐａｃｅ＿ｃｏｕｎｔ；｝　　　
　ｉｎｔ　　　　　　　　ｎｕｍ＿ｓｕｂｓｐａｃｅｓ
（）　｛ｒｅｔｕｒｎ　ｓｕｂｓｐａｃｅ＿ｃｏｕｎｔ
；｝　　　　ｉｎｔ　　　　　　　　ｎｕｍ＿ｓｙｍｂ
ｏｌｓ（）　｛ｒｅｔｕｒｎ　ｓｙｍ＿ｃｏｕｎｔ；｝
　　　　ｉｎｔ　　　　　　　　ｎｕｍ＿ｉｎｉｔ＿ｐ
ｔｒｓ（）　｛ｒｅｔｕｒｎ　ｉｎｉｔ＿ｐｔｒｓ＿ｃ
ｏｕｎｔ；｝　　　　ｕｎｓｉｇｎｅｄ　ｉｎｔ　ｄｐ
（）　｛ｒｅｔｕｒｎ　ｈｅａｄｅｒ＿ｐｔｒ−＞ｐｒ
ｅｓｕｍｅｄ＿ｄｐ；｝　　　　ＳＰＡＨＤＲ　　　　
＊ｇｅｔ＿ｓｐａｃｅ＿ｄｉｃｔ（）　｛ｒｅｔｕｒｎ
　ｓｐａｃｅ＿ｄｉｃｔ；｝　　　　ＳＣＮＨＤＲ　　
　　＊ｇｅｔ＿ｓｕｂｓｐａｃｅ＿ｄｉｃｔ（）　｛ｒ
ｅｔｕｒｎ　ｓｕｂｓｐａｃｅ＿ｄｉｃｔ；｝　　　　
ＳＹＭＥＮＴ　　　　＊ｇｅｔ＿ｓｙｍｂｏｌｓ（）　
｛ｒｅｔｕｒｎ　ｓｙｍ；｝　　　　ＩＮＩＴＰＴＲ　
　　＊ｇｅｔ＿ｉｎｉｔ＿ｐｔｒｓ（）　｛ｒｅｔｕｒ
ｎ　ｉｎｉｔ＿ｐｔｒｓ；｝　　　　ＳＰＡＨＤＲ　　
　　＊ｆｉｎｄ＿ｓｐａｃｅ（ｃｈａｒ　＊）；　　　
　ｃｈａｒ　　　　　　＊ｓｐａｃｅ＿ｎａｍｅ（ＳＰ
ＡＨＤＲ＆　ｓ）；　　　　　　　　　　　　　　　｛ 　　　　　　　　　　　　　　　　　　　ｒｅｔｕｒｎ
　＆ｓｐａｃｅ＿ｓｔｒｉｎｇｓ［ｓ．ＳＴＲ＿ＩＮＤ
ＥＸ］；　　　　　　　　　　　　　　　｝ 　　　　ＳＣＮＨＤＲ　　　　＊ｆｉｎｄ＿ｓｕｂｓｐ
ａｃｅ（ＳＰＡＨＤＲ　＊，　ｃｈａｒ　＊）；　　　
　ｃｈａｒ　　　　　　＊ｓｕｂｓｐａｃｅ＿ｎａｍｅ
　（ＳＣＮＨＤＲ＆　ｓ）　　　　　　　　　　　　　
　　｛ 　　　　　　　　　　　　　　　　　　　ｒｅｔｕｒｎ
　＆ｓｐａｃｅ＿ｓｔｒｉｎｇｓ［ｓ．ＳＴＲ＿ＩＮＤ
ＥＸ］；　　　　　　　　　　　　　　　｝ 　　　　ＳＹＭＥＮＴ　　　　＊ｆｉｎｄ＿ｓｙｍｂｏ
ｌ（ｃｈａｒ　＊，　ＳＣＮＨＤＲ　＊ｓｕｂｓｐ　＝
　ＮＵＬＬ，　ｉｎｔ　ｔｙｐ　＝　−１）；　　　　
ｃｈａｒ　　　　　　　＊ｓｙｍ＿ｎａｍｅ　８ＳＹＭ
ＥＮＴ＆　ｓ）　　　　　　　　　　　　　　　｛ 　　　　　　　　　　　　　　　　　　　ｒｅｔｕｒｎ
　＆ｓｙｍｂｏｌ＿ｓｔｒｉｎｇｓ［ｓ．ｏｆｆｓｅｔ
］；　　　　　　　　　　　　　　　｝ 　　　　ｌｏｎｇ　　　　　　　ｓｙｍ＿ｌｏｃ　（Ｓ
ＹＭＥＮＴ＆　ｓ）；　／／　ファイル中でｓｙｍが指
す位置　　　　ｌｏｎｇ　　　　　　　ｓｙｍ＿ｖａｌ
　（ＳＹＭＥＮＴ＆　ｓ）；　／／　ファイル中でロー
ドされた　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　／／　プログラ
ムが指す位置｝； 【００７７】３．１．２　特殊化クラス特殊化クラスは
、コンパイラ及びトランスレータデバッグ情報１２６、
３０６に対する読み書を行うルーチンを含む。特殊化ク
ラスは、オブジェクト／デバッグファイル１１８、３０
６を他のオブジェクト／デバッグファイル（代替デバッ
グテーブルが入っている）にコピーし、シンボルをオブ
ジェクト／デバッグファイル１１８、３０６に入ってい
るシンボルテーブルに追加するルーチンも含んでいる。 【００７８】本発明の好適実施例２２８では、ｄｅｂｕ
ｇｓｏｍ３００及びｄｅｂｕｇｓｏｍ８００という２つ
の特殊化クラスがある。 ｄｅｂｕｇｓｏｍ３００はＨＰ９０００シリーズ３００
コンピュータプラットフォーム２０２で動作し、ｄｅｂ
ｕｇｓｏｍ８００はＨＰ９０００シリーズ６００及び８
００コンピュータプラットフォーム２０２で動作する。 ｄｅｂｕｇｓｏｍ３００及びｄｅｂｕｇｓｏｍ８００に
ついて次の章で説明する。 【００７９】３．１．２．１　クラスｄｅｂｕｇｓｏｍ
３００クラスｄｅｂｕｇｓｏｍ３００を構成するコンピ
ュータプログラムセグメントを表４に示す。 【００８０】 　　　　　　　　　〈表−４〉 ｃｌａｓｓ　ｄｅｂｕｇｓｏｍ３００　：　ｐｕｂｌｉ
ｃ　ｓｏｍ３００　｛　　ｐｒｏｔｅｃｔｅｄ： 　　　　ｌｏｎｇ　　　　　　　ｌａｓｔ＿ｗｒｉｔｔ
ｅｎ＿ｐｏｓ；　／／　最後の書込位置を憶えておく　
　ｐｕｂｌｉｃ： 　　　　／／　コンストラクタ 　　　　ｄｅｂｕｇｓｏｍ３００（）；　　　　ｄｅｂ
ｕｇｓｏｍ３００（ｃｈａｒ　＊ｆｉｌｅｎａｍｅ，　
ｉｎｔ　ｍｏｄｅ＝ｉｏｓ：：ｉｎ）；　／／　ファイ
ル名で　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　／／　初期化する　　　　／／　デストラクタ
はない 　　　　／／　（ｓｅｅｋｐのために）最後の書込位置
を返す　　　　ｉｎｔ　　　　　　　　ｅｎｄｐｏｓ（
）　｛ｒｅｔｕｒｎ　ｌａｓｔ＿ｗｒｉｔｔｅｎ＿ｐｏ
ｓ；｝　　　　／／　デバッグ情報を読み書きする　　
　　ｄｅｂｕｇｉｎｆｏ　＊ｒｅａｄ＿ｄｅｂｕｇ＿ｉ
ｎｆｏ（）；　　　　ｉｎｔ　　　　　　　　ｗｒｉｔ
ｅ＿ｄｅｂｕｇ＿ｉｎｆｏ（ｄｅｂｕｇｉｎｆｏ　＊ｎ
ｅｗ＿ｄｂｇ＿ｉｎｆｏ）；　　　　／／　シンボルテ
ーブルにシンボルを付加する　　　　ｓｙｍｅｎｔ３０
０　＊ａｄｄ＿ｓｙｍｂｏｌ（ｃｈａｒ　＊ｎｍ，　ｉ
ｎｔ　ｓｙｍ＿ｔｙｐ，　ｉｎｔ　ｄｒｅｌｏｃ　＝　
０）；　　　　／／　力仕事ルーチン：ｏｌｄｓｏｍを
＊ｔｈｉｓに複写して、　　　　／／　　　デバッグ情
報をｃｐｐ＿ｉｎｆｏで置き換える　　　　ｉｎｔ　　
　　　　　　ｃｏｐｙ（ｄｅｂｕｇｓｏｍ３００＆　ｏ
ｌｄｓｏｍ，　ｄｅｂｕｇｉｎｆｏ　＊ｃｐｐ＿ｉｎｆ
ｏ）；｝； 【００８１】ルーチンｄｅｂｕｇｓｏｍ３００（）はオ
ブジェクト／デバッグファイル１１８、３０６をオープ
ンし、その内容の一部を読出す。ルーチンｒｅａｄ＿ｄ
ｅｂｕｇ＿ｉｎｆｏ（）はファイル１１８、３０６にア
クセスしてその内容の残りを読出す。 【００８２】ルーチンｒｅａｄ＿ｄｅｂｕｇ＿ｉｎｆｏ
（）はまた情報をデバッグデータ構造（表１に示す）に
書き込む。 【００８３】３．１．２．２　クラスｄｅｂｕｇｓｏｍ
８００クラスｄｅｂｕｇｓｏｍ８００を構成するコンピ
ュータプログラムセグメントを表５に示す。クラスｄｅ
ｂｕｇｓｏｍ８００に含まれているクラス、データ構造
及び機能は、ｄｅｂｕｇｓｏｍ３００クラス中のものと
相似である。 【００８４】 　　　　　　　　　〈表−５〉 ｃｌａｓｓ　ｄｅｂｕｇｓｏｍ８００　：　ｐｕｂｌｉ
ｃ　ｓｏｍ８００　｛　　ｐｒｏｔｅｃｔｅｄ： 　　　　ｉｎｔ　　　　　　　　ｌａｓｔ＿ｗｒｉｔｔ
ｅｎ＿ｐｏｓ；　／／　最後の書込位置　　　　／／　
手入れ情報を書き出すためのルーチン　　　　ｉｎｔ　
　　　　　　　　　　　ｃｏｐｙ＿ｏｌｄ＿ｆｉｘｕｐ
ｓ（ｄｅｂｕｇｓｏｍ８００＆　ｎｅｗｓｏｍ）；　　
　　ｉｎｔ　　　　　　　　　　　　ａｄｄ＿ｎｅｗ＿
ｆｉｘｕｐｓ（ｖｏｉｄ）；　　ｐｕｂｌｉｃ： 　　　　／／　コンストラクタ 　　　　ｄｅｂｕｇｓｏｍ８００（）；　　　　ｄｅｂ
ｕｇｓｏｍ８００（ｃｈａｒ　＊ｆｉｌｅｎａｍｅ，　
ｉｎｔ　ｍｏｄｅ＝ｉｏｓ：：ｉｎ）；　／／　ファイ
ル名で　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　／／　初期化する　　　　／／　デストラクタ
はない 　　　　／／　（ｓｅｅｋｐのために）最後の書込位置
を返す　　　　ｉｎｔ　　　　　　　　ｅｎｄｐｏｓ（
）　｛ｒｅｔｕｒｎ　ｌａｓｔ＿ｗｒｉｔｔｅｎ＿ｐｏ
ｓ；｝　　　　／／　デバッグ情報を読み書きする　　
　　ｄｅｂｕｇｉｎｆｏ　＊ｒｅａｄ＿ｄｅｂｕｇ＿ｉ
ｎｆｏ（）；　　　　ｉｎｔ　　　　　　　　ｗｒｉｔ
ｅ＿ｄｅｂｕｇ＿ｉｎｆｏ（ｄｅｂｕｇｉｎｆｏ　＊ｎ
ｅｗ＿ｄｂｇ＿ｉｎｆｏ）；　　　　／／　シンボルテ
ーブルにシンボルを付加する　　　　ｓｙｍｅｎｔ８０
０　＊ａｄｄ＿ｓｙｍｂｏｌ（ｃｈａｒ　＊ｎｍ，　ｉ
ｎｔ　ｓｙｍ＿ｔｙｐ，　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　ｉｎｔ
　ｓｙｍ＿ｓｃｏｐｅ，　ｉｎｔ　ｓｕｂｓｐ）；　　
　　 　　　　／／　力仕事ルーチン：ｏｌｄｓｏｍを＊ｔｈ
ｉｓに複写して、　　　　／／　　　デバッグ情報をｃ
ｐｐ＿ｉｎｆｏで置き換える　　　　ｉｎｔ　　　　　
　　　ｃｏｐｙ（ｄｅｂｕｇｓｏｍ８００＆　ｏｌｄｓ
ｏｍ，　ｄｅｂｕｇｉｎｆｏ　＊ｃｐｐ＿ｉｎｆｏ）；
　　　　／／　古い手入れ情報を読む 　　　　ｆｒｉｅｎｄ　ｏｌｄｆｉｘｕｐｌｉｓｔ　＊
ｒｅａｄ＿ｄｅｂｕｇ＿ｆｉｘｕｐｓ（ｄｅｂｕｇｓｏ
ｍ８００＆，　ｉｎｔ，　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　ｃｈａ
ｒ　＊）；｝； 【００８５】３．２　デバッグ情報マニピュレータ図７
は、デバッグ情報マニピュレータ５１０の構造図／機能
フローチャートを示す。図７で、長方形は、ソフトウェ
アモジュール／プロセスを表わし、長円形は、ソフトウ
ェアモジュール／プロセスの入力及び出力を表わす。 【００８６】図７に示す通り、デバッグ情報マニピュレ
ータは、ルックアップテーブル構築部７１０、７１２、
ルックアップテーブル整合部（ｌｏｏｋｕｐ　ｔａｂｌ
ｅ　ｍａｔｃｈｅｒ）７２６及びルックアップテーブル
調整部（ｌｏｏｋｕｐ　ｔａｂｌｅ　ｆｉｘｅｒ）７４
４を含んでいる。 【００８７】図８は、デバッグ情報マニピュレータ５１
０のフローチャートを示す（図８のフローチャートは、
図６のステップ６１０の動作をもっと詳細に見たもので
ある）。デバッグ情報マニピュレータ５１０の動作を、
今度は図５、図７及び図８を参照して説明する。 【００８８】ステップ８０２で、ルックアップテーブル
構築部７１０及び７１２は、コンパイラデバッグデータ
構造５１６及びトランスレータデバッグデータ構造５１
８を受取って、コンパイラルックアップテーブル７１８
及びトランスレータルックアップテーブル７２０を作る
。ルックアップテーブル７１８及び７２０は、ルックア
ップテーブル７１８、７２０がＤＮＴＴの正確なブロッ
ク構造を反映し、各入れ子ブロックテーブルが意味のあ
るＤＮＴＴのエントリ全てについてのエントリを含んで
いるという点で、それぞれコンパイラデバッグデータ構
造５１６及びトランスレータデバッグデータ構造５１８
中に含まれているＤＮＴＴを抽象化したものである。 【００８９】ステップ８０６で、ルックアップテーブル
整合部７２６は、ルックアップテーブル７１８、７２０
を整合（ｍａｔｃｈ）させて整合済みコンパイラルック
アップテーブル（ｍａｔｃｈｅｄ　ｃｏｍｐｉｌｅｒ　
ｌｏｏｋｕｐ　ｔａｂｌｅ）７３２及び整合済みトラン
スレータルックアップテーブル（ｍａｔｃｈｅｄ　ｔｒ
ａｎｓｌａｔｏｒ　ｌｏｏｋｕｐ　ｔａｂｌｅ）７３４
をそれぞれ作製する。ステップ８０６が終了すると、整
合済みコンパイラルックアップテーブル７３２のエント
リは整合済みトランスレータルックアップテーブル７３
４のエントリと整合している、つまり対応するようにな
っている。 【００９０】ステップ８１０で、ルックアップテーブル
調整部７４４が整合ルックアップテーブル７３２、７３
４を調整する。この調整過程中、ルックアップテーブル
調整部は、情報を整合済みコンパイラルックアップテー
ブル７３２から整合済みトランスレータルックアップテ
ーブル７３４にコピーする。 【００９１】具体的には、ルックアップテーブル調整部
７４４は、整合ルックアップテーブル７３２、７３４を
走査して全ての可能且つ必要な情報を整合済みコンパイ
ラルックアップテーブル７３２のエントリからその対応
する整合済みトランスレータルックアップテーブル７３
４のエントリにコピーする。調整する必要のあるフィー
ルドについて、ルックアップテーブル調整部７４４は、
出力オブジェクトファイルインターフェース５１４につ
いての「新しい決定用情報」ノードを作り出す。 【００９２】整合済みコンパイラルックアップテーブル
７３２から整合済みトランスレータルックアップテーブ
ルにコピーされる情報には、デバッグ用名前及び型テー
ブル（ＤＮＴＴ）、ソース行テーブル（ＳＬＴ）及びポ
ータブル決定用情報リストがある。（上に説明したよう
に、この情報はルックアップテーブル７１８、７２０に
入っている。） 【００９３】具体的には、整合済みトランスレータルッ
クアップテーブルに入っているＤＮＴＴの各種のエント
リの値は、整合済みコンパイラルックアップテーブル７
３２からの情報を用いて修正されなければならない。こ
のようなＤＮＴＴエントリにはＳＶＡＲエントリがある
が、そのロケーション及びオフセット値は整合済みコン
パイラルックアップテーブル７３２からの情報を用いて
修正されなければならない。他のこのようなＤＮＴＴエ
ントリにはＤＶＡＲ及びＦＰＡＲＡＭのエントリがあり
、これらのロケーション及びレジスタパラメータ値は整
合済みコンパイラルックアップテーブル７３２からの情
報を用いて修正されなければならない。 【００９４】他のそのようなＤＮＴＴエントリにはＦＵ
ＮＣエントリがあり、そのｅｎｔｒｙａｄｄｒ、ｌｏｗ
ａｄｄｒ、ｈｉａｄｄｒ、ａｄｄｒ及び最適化値は、整
合済みコンパイラルックアップテーブル７３２からの情
報を用いて修正されなければならない。 【００９５】他のそのようなＤＮＴＴエントリには、Ｂ
ＥＧＩＮ、ＥＮＤ、ＣＬＡＳＳ＿ＳＣＯＰＥ、ＷＩＴＨ
、ＬＡＢＥＬ及びＯＢＪＥＣＴ＿ＩＤの各エントリがあ
り、それらのアドレス値は整合済みコンパイラルックア
ップテーブル７３２からの情報を用いて修正されなけれ
ばならない。 【００９６】また、ルックアップテーブル調整部７４４
は、整合済みコンパイラルックアップテーブル７３２に
入っているＳＬＴを使用して整合済みトランスレータル
ックアップテーブル７３４のためのＳＬＴを作り出す。 ＳＬＴは、ステートメント及びブロックの始めと終りの
ロケーションを示す情報を含んでいる。 【００９７】整合済みトランスレータルックアップテー
ブル７３４のためのＳＬＴを作り出しながら、ルックア
ップテーブル調整部７４４は、ＢＥＧＩＮ及びＥＮＤの
ような、スコープに関係するＳＬＴエントリをそれらの
対応するＤＮＴＴエントリと整合させる。従って、ルッ
クアップテーブル調整部７４４は、ソースコード１０２
のブロック構造を正しく反映するＤＮＴＴ及びＳＬＴの
エントリの整合した組合せが得られてそれが整合トラン
スレータルックアップテーブル７３４に格納されるまで
、ＳＬＴエントリを追加及び削除し、整合しないＤＮＴ
Ｔエントリを無効にする。整合しないＳＬＴ及びＤＮＴ
Ｔエントリには除去用の印を付ける。 【００９８】多くの場合、整合済みトランスレータルッ
クアップテーブル７３４に挿入しなければならない情報
は、リンク時点までわからない。例えば、静的変数のア
ドレス、あるいは関数の開始及び終りについてのコード
アドレスは、リンクするまでわからない。 【００９９】これらの場合には、ルックアップテーブル
調整部７４４は、決定用情報（ｆｉｘｕｐ）を作り出し
て、リンカ１２８にリンクプロセス中適切な値をオブジ
ェクトコード３１６中の最終デバッグ情報に挿入するよ
う指示する。 【０１００】決定用情報は、ＤＮＴＴのＳＶＡＲ、ＦＵ
ＮＣ及びＯＢＪＥＣＴ＿ＩＤの各エントリについて作ら
なければならない。 【０１０１】ステップ８１４で、ルックアップテーブル
調整部７４４は整頓段階に入り、除去用の印が付いてい
るＳＬＴ及びＤＮＴＴを削除する（ＳＬＴエントリの場
合）かまたは無効にする（ＤＮＴＴエントリの場合）。 【０１０２】ステップ８１０及び８１４の終了に続いて
、図７に示すように、ルックアップテーブル調整部７４
４は、マージ済みルックアップテーブル５２８を出力す
るが、これには整合ルックアップテーブル７３４及び決
定用情報リスト５３０が入っている。 【０１０３】図８のステップ８０２、８０４、８１０及
び８１４について、次章で更に詳細に説明する。 【０１０４】３．２．１　ステップ８０２−ルックアッ
プテーブルを構築するルックアップテーブル構築部７１
０、７１２により発生されたルックアップテーブル７１
８、７２０は、ブロック構造を持つ入れ子になったテー
ブルで、ＤＮＴＴのエントリを保持するのに使用される
。プロック構造は次のＤＮＴＴ対の形で表わされる。 ・　Ｋ＿ＭＯＤＵＬＥ　と　Ｋ＿ＥＮＤ　・　Ｋ＿ＦＵ
ＮＣＴＩＯＮ　と　Ｋ＿ＥＮＤ　・　Ｋ＿ＢＥＧＩＮ　
と　Ｋ＿ＥＮＤ　【０１０５】このような対は、各々別
個のクラスで表わされるが、これらクラスは皆ｄｔａｂ
と呼ばれる共通基底クラスから誘導される。 【０１０６】例えば、下記のコンピュータプログラムの
抜粋を考える。 【０１０７】ｉｎｔ　ｖｌ； ｍａｉｎ　（ｉｎｔ　ａｒｇｃ，　ｃｈａｒ　＊＊ａｒ
ｇｖ）｛ ｉｎｔ　ｋ　＝　ａｒｇｃ； ｉｆ（　ｋ　＞　１　）　｛ ｃｈａｒ＊　ｆｏｏ　＝　ａｒｇｖ［０］；｝ ｉｎｔ　ｊ　＝　ｋ　／　２； ｊ　＋＝　２； ｉｆ（　ｊ　＞　３　）　｛ ｃｈａｒ　＊ｆｏｏ　＝　ａｒｇｖ［１］；｝ ｝ ｉｎｔ　ｖ２； 【０１０８】以下の表６は、ルックアップテーブル構築
部７１０，７１２がこのプログラム抜粋をルックアップ
テーブル７１８、７２０中で表わす方法を示している。 【０１０９】 　　　　　　　　　〈表−６〉 ＴＡＢＬＥ　（Ｓｔａｒｔ　ＮＴＴ：　０；　Ｅｎｄ　
ＮＴＴ：　０；　Ｓｒｃｆ：　０）　　ＭＯＤＵＬＥ　
（Ｎａｍｅ：　＜＜＜ＮＵＬＬ＿ＳＹＭＢＯＬ＞＞＞；
　Ａｌｉａｓ：　；　Ｓｔａｒｔ　ＮＴＴ：　４０００
８９８８；　　　　　　　　　　Ｅｎｄ　ＮＴＴ：　４
０００８９８８；　Ｓｔａｒｔ　ＳＬＴ：　−１；　Ｅ
ｎｄ　ＳＬＴ：　−１；　Ｓｒｃｆ：　０）　　　　　
　Ｓｒｃ　（Ｎａｍｅ：　ｔ１．ｃ；　ＮＴＴ：　４０
００８９ａ０；　ＳＬＴ：　−１）　　　　　　Ｓｖａ
ｒ　（Ｎａｍｅ：　ｖ１；　ＮＴＴ：　４０００８ａａ
８；　Ｏｆｆ：　０；　ｄｉｓｐ：　０；　ｌｏｃ：　
０；　　　　　　　　　　　　ｓｙｍ：　０；　Ｓｒｃ
ｆ：　０）　　　　　　Ｓｖａｒ　（Ｎａｍｅ：　ｖ２
；　ＮＴＴ：　４０００８ａｃ０；　ｏｆｆ：　０；　
ｄｉｓｐ：　０；　ｌｏｃ：　０；　　　　　　　　　
　　　ｓｙｍ：　０；　Ｓｒｃｆ：　０）　　　　　　
ＦＵＮＣＴＩＯＮ　（Ｎａｍｅ：　ｍａｉｎ；　Ａｌｉ
ａｓ：　＿ＭＡＩＮ＿；　Ｓｔａｒｔ　ＮＴＴ：　４０
００８９ａｃ；　　　　　　　　　　　　　　　　Ｅｎ
ｄ　ＮＴＴ：　４０００８９ａｃ；　Ｓｔａｒｔ　ＳＬ
Ｔ　−１；　Ｅｎｄ　ＳＬＴ：　−１；　　　　　　　
　　　　　　　　　Ｓｒｃｆ：　４０００９７ｃ８）　
　　　　　　　　　Ｆｐａｒａｍ　（Ｎａｍｅ：　ａｒ
ｇｃ；　ＮＴＴ：　４０００８９ｄ０；　ｓｐｏｆｆ：
　０；　　　　　　　　　　　　　　　　　　Ｓｒｃｆ
：　４０００９７ｃ８）　　　　　　　　　　Ｆｐａｒ
ａｍ　（Ｎａｍｅ：　ａｒｇｖ；　ＮＴＴ：　４０００
８ａ００；　ｓｐｏｆｆ：　０；　　　　　　　　　　
　　　　　　　　Ｓｒｃｆ：　４０００９７ｃ８）　　
　　　　　　　　ＢＬＯＣＫ　（Ｓｔａｒｔ　ＮＴＴ：
　４０００８ａ１８；　Ｅｎｄ　ＮＴＴ：　４０００８
ａ１８；　　　　　　　　　　　　　　　　　Ｓｔａｒ
ｔ　ＳＬＴ：　−１；　　　　　　　　　　　　　　　
　　Ｅｎｄ　ＳＬＴ：　−１；　Ｓｒｃｆ：　４０００
９７ｃ８）　　　　　　　　　　　　　　Ｄｖａｒ　（
Ｎａｍｅ：　ｊ；　ＮＴＴ：　４０００８ａ３ｃ；　ｓ
ｐｏｆｆ：　０；　　　　　　　　　　　　　　　　　
　　　Ｓｒｃｆ：　４０００９７ｃ８）　　　　　　　
　　　　　　　Ｄｖａｒ　（Ｎａｍｅ：　ｋ；　ＮＴＴ
：　４０００８ａ２４；　ｓｐｏｆｆ：　０；　　　　
　　　　　　　　　　　　　　　　Ｓｒｃｆ：　４００
０９７ｃ８）　　　　　　　　　　　　　　ＢＬＯＣＫ
　（Ｓｔａｒｔ　ＮＴＴ：　３０００８ａ５４；　Ｅｎ
ｄ　ＮＴＴ：　４０００８ａ５４；　　　　　　　　　
　　　　　　　　　　　　Ｓｔａｒｔ　ＳＬＴ：　−１
；　　　　　　　　　　　　　　　　　　　　　Ｅｎｄ
　ＳＬＴ：　−１；　Ｓｒｃｆ：　４０００９７ｃ８）
　　　　　　　　　　　　　　　　　　Ｄｖａｒ　（Ｎ
ａｍｅ：　ｆｏｏ；　ＮＴＴ：　４０００８ａ６ｃ；　
ｓｐｏｆｆ：　０；　　　　　　　　　　　　　　　　
　　　　　　　　Ｓｒｃｆ：　４０００９７ｃ８）　　
　　　　　　　　　　　　ＢＬＯＣＫ　（Ｓｔａｒｔ　
ＮＴＴ：　４０００８ａ９０；　Ｅｎｄ　ＮＴＴ：　４
０００８ａ９０；　　　　　　　　　　　　　　　　　
　　　　Ｓｔａｒｔ　ＳＬＴ：　−１；　　　　　　　
　　　　　　　　　　　　　　Ｅｎｄ　ＳＬＴ：　−１
；　Ｓｒｃｆ：　０）　　　　　　　　　　　　　　　
　　　Ｄｖａｒ　（Ｎａｍｅ：　ｆｏｏ；　ＮＴＴ：　
４０００８ａａ８；　ｓｐｏｆｆ：　０；　　　　　　
　　　　　　　　　　　　　　　　　　Ｓｒｃｆ：　０
） 【０１１０】表６の中の表現の中で注意しておくべき特
徴がいくつかある。第１に、各「ブロック」は１つのテ
ーブルで表わされている。最も外側のレベル（グローバ
ルレベル）は、テーブルＭＯＤＵＬＥで表わされている
。（実際には、最も外側レベルは外側のＴＡＢＬＥで表
わすべきであるが、ＤＮＴＴ＿ＭＯＤＵＬＥエントリに
対するテーブルを作る準備を行わなければならない。）
「関数」レベルのブロックはテーブルＦＵＮＣＴＩＯＮ
で表わされる。内部ブロックは全てテーブルＢＬＯＣＫ
で表わされる。 【０１１１】第２に、テーブルノードは幾らかの一般情
報を含んでおり、テーブル型は幾らかの型固有の情報を
持っている。具体的には、ブロックの始めと終りに対応
するＤＮＴＴエントリへのポインタは、ブロックの始め
の直前及び終りの直前（表６には示されていない）に見
られる直前のＤＮＴＴ＿ＳＯＵＲＣＥＦＩＬＥへのポイ
ンタのように、全てのテーブルについて格納される。 【０１１２】また、ＳＬＴ内の対応するブロックの始め
と終りに対するＳＬＴインデクスは、全ての関数、ブロ
ック及びモジュールについて格納される。また、名前及
びエイリアスをへのポインタが全ての関数、ブロック及
びモジュールについて格納される。 【０１１３】第３に、ブロック内の全てのエントリは、
ハッシングされてそのブロックに対応するテーブルに入
れられている。色々な型のエントリが生成され、その各
々はそのエントリの型に対応する幾らかの特定の情報を
持っている。 【０１１４】最後に、エクスポート及びインポートされ
たグローバル変数（ＧＮＴＴに対応する）についての他
のＴＡＢＬＥテーブルが生成される（表６には示されて
いない）。このテーブルはブロック構造を有していない
。 【０１１５】本発明の好適実施例では、ブロック構造対
を表わす以下の５つのクラスがある：ｄａｔａｂ，　ｂ
ｌｏｃｋｔａｂ，　ｆｕｎｃｔａｂ，　ｍｏｄｔａｂ，
及びｎｕｌｌｔａｂである。これらクラスについて次章
で詳細に説明する。 【０１１６】３．２．１．１　クラスｄｔａｂｄｔａｂ
は、ルックアップテーブル７１８、７２０の機能のほと
んどを実現する基底クラスである。ｄｔａｂクラスは、
エントリのためのハッシュテーブル、サブテーブルのリ
ストへのポインタ、その直接の親テーブルへの逆方向ポ
インタを含む。 【０１１７】これに加えて、ｄｔａｂクラスは、反復の
間の状態を保持するメンバと、ある重要なデバッグ構造
へのポインタを含む。 【０１１８】ｄｔａｂは抽象基底クラスである（表７中
の宣言ｔｔｙｐ（）を参照）。 【０１１９】ｄｔａｂクラスを構成するクラス、データ
構造、変数及び関数を表７に示す。 【０１２０】 　　　　　　　　　〈表−７〉 ｃｌａｓｓ　ｄｔａｂ　｛ 　　ｐｒｉｖａｔｅ： 　　　　ｄｓｙｍｅｎｔ　＊＊ｅｎｔ；　　　　　　　
　　　　　　　／／　要素用のハッシュテーブル　　　
　ｉｎｔ　ｎｕｍｂｕｃｋｅｔｓ，　ｎｕｍｔａｂｌｅ
ｓ；　　　　ｄｔａｂｌｉｓｔ　＊ｆｉｒｓｔｃｈｉｌ
ｄ；　　　　　　　／／　テーブルの下位リストへの　
　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　／／　ポインタ　　　　ｄｔａｂ　＊
ｐａｒｅｎｔ；　　　　　　　　　　　　　　　／／　
親テーブルへのポインタ　　　　ｄｔａｂｌｉｓｔ　＊
ｎｅｘｔｃｈｉｌｄ；　　　　　　　　／／　反復子が
使用　　　　ｄｎｔｔｅｎｔｒｙ　＊ｎｔｔ＿ｓｔａｒ
ｔ，　＊ｎｔｔ＿ｅｎｄ；　　／／　テーブルの付き合
わせ及び　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　／／　手当をす
るルーチンが使用　　　　ＳＬＴＰＯＩＮＴＥＲ　ｓｌ
ｔ＿ｓｔａｒｔ，　ｓｌｔ＿ｅｎｄ；　　　／／　同　
　上　　　　ｄｔａｂ　＊ｃｏｒｒｅｓｐｏｎｄｉｎｇ
；　　　　　　　　　　　　　／／　同　　上　　　　 　　　　ｄｓｒｃｅｎｔ　＊ｓｒｃｆ，　＊ｅｓｒｃｆ
；　　　　　　／／　ソースファイルテーブル要素への
　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　／／　ポインタ　　　　ｆａｋｅｂ
ｌｏｃｋ　＊ｎ＿ｆａｋｅｓ；　　　　　　　　　／／
　このブロック内の　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　／／　「フェイク
（模造）」ブロック　　ｐｒｏｔｅｃｔｅｄ： 　　　　ｉｎｔ　ｍａｋｅ＿ｔａｂｌｅ（ｉｎｔ　ｂｕ
ｃｋｅｔｓ）；　／／　コンストラクタから呼ばれる　
　ｐｕｂｌｉｃ： 　　　　／／　コンストラクタ及びデストラクタ　　　
　ｄｔａｂ（）　｛ｍａｋｅ＿ｔａｂｌｅ（ＤＴＡＢＳ
ＩＺ）；｝　　　　ｄｔａｂ（ｉｎｔ　ｂｕｃｋｅｔｓ
）　｛ｍａｋｅ＿ｔａｂｌｅ（ｂｕｃｋｅｔｓ）；｝　
　　　ｖｉｒｔｕａｌ　■ｄｔａｂ（）；　　　　／／
　テーブル操作ルーチン 　　　　ｉｎｔ　ｈａｓｈ（ｃｈａｒ　＊）；　　　　
ｉｎｔ　ｉｎｓｅｒｔ（ｄｓｙｍｅｎｔ　＊ｅｎｔｒｙ
）；　　　　ｉｎｔ　ｒｅｍｏｖｅ（ｄｓｙｍｅｎｔ　
＊ｅｎｔｒｙ）；　　　　ｄｓｙｍｅｎｔ　＊ｌｏｏｋ
ｕｐ　（ｃｈａｒ　＊ｎ，　ｉｎｔ　ｎｏｆｏｌｌｏｗ
＝０，　　　　　　　　　　　　　　　　　　　　　　
　　　ｉｎｔ　ｋｉｎｄ＝Ｋ＿ＮＩＬ）；　　　　ｉｎ
ｔ　ａｄｄ＿ｓｕｂｔａｂｌｅ　（ｄｔａｂ　＊ｓｕｂ
ｔａｂ）；　　　　／／　このテーブルは何か「実際」
の要素を含んでいるか？　　　　ｉｎｔ　ｅｍｐｔｙ（
）； 　　　　／／　デバッグ情報のためのアクセスルーチン
　　　　ｖｏｉｄ　ｓｅｔ＿ｓｌｔ＿ｓｔａｒｔ（ＳＬ
ＴＰＯＩＮＴＥＲ　ｎ）　｛ｓｌｔ＿ｓｔａｒｔ　＝　
ｎ；｝　　　　ｖｏｉｄ　ｓｅｔ＿ｓｌｔ＿ｅｎｄ（Ｓ
ＬＴＰＯＩＮＴＥＲ　ｎ）　｛ｓｌｔ＿ｓｔａｒｔ　＝
　ｎ；｝　　　　ＳＬＴＰＯＩＮＴＥＲ　ｇｅｔ＿ｓｌ
ｔ＿ｓｔａｒｔ（）　｛ｒｅｔｕｒｎ　ｓｌｔ＿ｓｔａ
ｒｔ；｝　　　　ＳＬＴＰＯＩＮＴＥＲ　ｇｅｔ＿ｓｌ
ｔ＿ｅｎｄ（）　｛ｒｅｔｕｒｎ　ｓｌｔ＿ｅｎｄ；｝
　　　　ｖｏｉｄ　ｓｅｔ＿ｎｔｔ＿ｓｔａｒｔ　（ｄ
ｎｔｔｅｎｔｒｙ　＊ｎｔｔ）　｛ｎｔｔ＿ｓｔａｒｔ
　＝　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　
　　ｎｔｔ；｝　　　　ｖｏｉｄ　ｓｅｔ＿ｎｔｔ＿ｅ
ｎｄ　（ｄｎｔｔｅｎｔｒｙ　＊ｎｔｔ）　｛ｎｔｔ＿
ｅｎｄ　＝　ｎｔｔ；｝　　　　ｄｎｔｔｅｎｔｒｙ　
＊ｇｅｔ＿ｎｔｔ＿ｓｔａｒｔ　（）　｛ｒｅｔｕｒｎ
　ｎｔｔ＿ｓｔａｒｔ；｝　　　　ｄｎｔｔｅｎｔｒｙ
　＊ｇｅｔ＿ｎｔｔ＿ｅｎｄ　（）　｛ｒｅｔｕｒｎ　
ｎｔｔ＿ｅｎｄ；｝　　　　ｖｏｉｄ　ｓｅｔ＿ｓｏｕ
ｒｃｅｆｉｌｅ（ｄｓｒｃｅｎｔ　＊ｘ）　｛ｓｒｃｆ
　＝　ｘ；｝　　　　ｖｏｉｄ　ｓｅｔ＿ｅｎｄｓｏｕ
ｒｃｅｆｉｌｅ（ｄｓｒｃｅｎｔ　＊ｘ）　｛ｅｓｒｃ
ｆ　＝　ｘ；｝　　　　ｄｓｒｃｅｎｔ　＊ｓｏｕｒｃ
ｅｆｉｌｅ（）　｛ｒｅｔｕｒｎ　ｓｒｃｆ；｝　　　
　ｄｓｒｃｅｎｔ　＊ｅｎｄｓｏｕｒｃｅｆｉｌｅ（）
　｛ｒｅｔｕｒｎ　ｅｓｒｃｆ；｝　　　　／／　フェ
イクブロックへのアクセスルーチン　　　　ｖｏｉｄ　
ｓｅｔ　ｆａｋｅｓ（ｆａｋｅｂｌｏｃｋ　＊ｆ）　｛
ｎ＿ｆａｋｅｓ　＝　ｆ；｝　　　　ｆａｋｅｂｌｏｃ
ｋ　＊ｆａｋｅｓ（）　｛ｒｅｔｕｒｎ　ｎ＿ｆａｋｅ
ｓ；｝　　　　／／　テーブル反復子 　　　　ｖｏｉｄ　ｉｔｅｒ＿ｓｔａｒｔ（）；　　　
　ｄｔａｂ　＊ｎｅｘｔｓｕｂｔａｂ（）；　　　　／
／　テーブルタイプ 　　　　ｖｉｒｔｕａｌ　ｉｎｔ　ｔｔｙｐ（）　＝　
０；　　　　／／　他のメンバ及びフレンドの宣言｝； 【０１２１】３．２．１．２　クラスｂｌｏｃｋｔａｂ
ｂｌｏｃｋｔａｂはｄｔａｂから誘導されたクラスであ
る。ｂｌｏｃｋｔａｂは全てのソースブロックの基底ク
ラスである。ｂｌｏｃｋｔａｂは、演算子ｔｔｙｐ（）
以外は、ｄｔａｂに追加して定義しているものはない。 ｔｔｙｐ（）は関数の内側の全ての｛｝内部のシンボル
を表わすのに使用される。 【０１２２】クラスｂｌｏｃｋｔａｂを構成するクラス
、データ構造、変数及び関数を表８に示す。 【０１２３】 〈表−８〉 ｃｌａｓｓ　ｂｌｏｃｋｔａｂ　：　ｐｕｂｌｉｃ　ｄ
ｔａｂ　｛ｐｕｂｌｉｃ： ／／　コンストラクタ ｂｌｏｃｋｔａｂ（）　｛｝ ／／　テーブルタイプ ｖｉｒｔｕａｌ　ｉｎｔ　ｔｔｙｐ（）；　　　　　　
／／　Ｋ＿ＢＥＧＩＮ｝； 【０１２４】３．２．１．３　クラスｆｕｎｃｔａｂｆ
ｕｎｃｔａｂは、ｂｌｏｃｋｔａｂから誘導されたクラ
スである。ｆｕｎｃｔａｂは、関数の最も外側のブロッ
クを表わすのに使用される。ｆｕｎｃｔａｂは関数の名
前及びエイリアスを定義する。ｆｕｎｃｔａｂはまた名
前及びエイリアスにアクセスして修正する一組のアクセ
スルーチンを定義する。 【０１２５】クラスｆｕｎｃｔａｂを構成するクラス、
データ構造、変数及び関数を表９に示す。 【０１２６】 〈表−９〉 ｃｌａｓｓ　ｆｕｎｃｔａｂ　：　ｐｕｂｌｉｃ　ｂｌ
ｏｃｋｔａｂ　｛ｐｒｉｖａｔｅ： ｃｈａｒ　＊ｎ＿ｎａｍｅ，　＊ｎ＿ａｌｉａｓ；　／
／　関数の名前とエイリアスｐｕｂｌｉｃ： ／／　コンストラクタ ｆｕｎｃｔａｂ（ｃｈａｒ　＊ｎ，　ｃｈａｒ　＊ａ）
；／／　名前とエイリアスへのアクセスルーチンｃｈａ
ｒ　＊ｎａｍｅ（）　｛ｒｅｔｕｒｎ　ｎ＿ｎａｍｅ；
｝ｃｈａｒ　＊ａｌｉａｓ（）　｛ｒｅｔｕｒｎ　ｎ＿
ａｌｉａｓ；｝ｖｏｉｄ　ｓｅｔ＿ｎａｍｅ　（ｃｈａ
ｒ　＊ｎ）　｛ｎ＿ｎａｍｅ　＝　ｎ；｝ｖｏｉｄ　ｓ
ｅｔ＿ａｌｉａｓ　（ｃｈａｒ　＊ｎ）　｛ｎ＿ａｌｉ
ａｓ　＝ｎ；｝／／　テーブルタイプ ｖｉｒｔｕａｌ　ｉｎｔ　ｔｔｙｐ（）；　　　　　　
／／　Ｋ＿ＦＵＮＣＴＩＯＮ｝； 【０１２７】３．２．１．４　クラスｍｏｄｔａｂｍｏ
ｄｔａｂはｂｌｏｃｋｔａｂから誘導されたクラスであ
る。ｍｏｄｔａｂは本質的にはｆｕｎｃｔａｂと同じで
あり、代わりにｆｕｎｃｔａｂから誘導することができ
る。 【０１２８】ｍｏｄｔａｂは関数ｔｔｙｐ（）を再定義
する。 【０１２９】クラスｍｏｄｔａｂを構成するクラス、デ
ータ構造、変数及び関数を表１０に示す。 【０１３０】 　　　　　　　　　　　　　　〈表−１０〉ｃｌａｓｓ
　ｎｕｌｌｔａｂ　：　ｐｕｂｌｉｃ　ｄｔａｂ　｛　
　ｐｕｂｌｉｃ： 　　　　／／　コンストラクタ 　　　　ｎｕｌｌｔａｂ（）　｛｝ 　　　　ｎｕｌｌｔａｂ（ｉｎｔ　ｂｕｃｋｅｔｓ）　
：　ｄｔａｂ（ｂｕｃｋｅｔｓ）　｛｝｝； ｃｌａｓｓ　ｍｏｄｔａｂ　：　ｐｕｂｌｉｃ　ｂｌｏ
ｃｋｔａｂ　｛　　ｐｒｉｖａｔｅ： 　　　　ｃｈａｒ　＊ｎ＿ｎａｍｅ，　＊ｎ＿ａｌｉａ
ｓ；　　／／　モジュールの名前とエイリアス　　ｐｕ
ｂｌｉｃ： 　　　　／／　コンストラクタ 　　　　ｍｏｄｔａｂ（ｃｈａｒ　＊ｎ，　ｃｈａｒ　
＊ａ）；　　　　／／　名前とエイリアスへのアクセス
ルーチン　　　　ｃｈａｒ　＊ｎａｍｅ（）　｛ｒｅｔ
ｕｒｎ　ｎ＿ｎａｍｅ；｝　　　　ｃｈａｒ　＊ａｌｉ
ａｓ（）　｛ｒｅｔｕｒｎ　ｎ＿ａｌｉａｓ；｝　　　
　ｖｏｉｄ　ｓｅｔ＿ｎａｍｅ　（ｃｈａｒ　＊ｎ）　
｛ｎ＿ｎａｍｅ　＝　ｎ；｝　　　　ｖｏｉｄ　ｓｅｔ
＿ａｌｉａｓ　（ｃｈａｒ　＊ｎ）　｛ｎ＿ａｌｉａｓ
　＝　ｎ；｝　　　　／／　テーブルタイプ 　　　　ｖｉｒｔｕａｌ　ｉｎｔ　ｔｔｙｐ（）；　　
　　　　／／　Ｋ＿ＭＯＤＵＬＥ｝； 【０１３１】３．２．１．５　クラスｎｕｌｌｔａｂｎ
ｕｌｌｔａｂはｄｔａｂから誘導されたクラスである。 ｎｕｌｌｔａｂは最も外側のレベルのローカル及びグロ
ーバルＮＴＴを表わすのに使用される。例えば、ＧＮＴ
ＴはグローバルなＳＶＡＲを全て含んでいるｎｕｌｌｔ
ａｂにより表わされる。同様に、ＬＮＴＴの中のｍｏｄ
ｔａｂはｎｕｌｌｔａｂの内側に包まれる。 【０１３２】クラスｎｕｌｌｔａｂの主な特徴は、色々
なハッシュテーブルサイズを与えてインスタンスを生成
することができることである（テーブルが本質的にフラ
ットで、小さなハッシュテーブルでは多数の衝突を引き
起こしてしまうＧＮＴＴに有用である）。 【０１３３】クラスｎｕｌｌｔａｂを構成するクラス、
データ構造、変数及び関数を表１１に示す。 【０１３４】 〈表−１１〉 ｃｌａｓｓ　ｐｕｂｌｉｃ　：　ｐｕｂｌｉｃ　ｄｔａ
ｂ　｛ｐｕｂｌｉｃ： ／／　コンストラクタ ｎｕｌｌｔａｂ（）　｛｝ ｎｕｌｌｔａｂ（ｉｎｔ　ｂｕｃｋｅｔｓ）　：　ｄｔ
ａｂ（ｂａｃｋｅｔｓ）　｛｝／／　テーブルタイプ ｖｉｒｔｕａｌ　ｉｎｔ　ｔｔｙｐ（）；　　　　　　
／／　Ｋ＿ＮＩＬ｝； 【０１３５】３．２．２　ステップ８０６−ルックアッ
プテーブルを整合させる ステップ８０６の期間中、ルックアップテーブル整合部
７２６は、コンパイラルックアップテーブル７１８のエ
ントリをトランスレータルックアップテーブル７２０の
エントリと整合させる。 【０１３６】図９は、ルックアップテーブル整合部７２
６の動作のフローチャートを示す（換言すれば、図９は
ステップ８０６の動作の詳細フローチャートを示す）。 ステップ９０２で、ルックアップテーブル整合部７２６
はルックアップテーブル７１８、７２０をその最もコン
パクトな形態に正規化する、すなわち縮約する。 【０１３７】ステップ９０６で、ルックアップテーブル
整合部７２６はトランスレータルックアップテーブル７
２０の深さ優先の走査を行い、トランスレータルックア
ップテーブル７２０中の要素をコンパイラルックアップ
テーブル７１８中でそれに対応する要素（またはその祖
先原型のうちの１つ）と整合させる。 【０１３８】ステップ９０２及び９０６を次章で更に詳
細に説明する。 【０１３９】３．２．２．１　ステップ９０２−ルック
アップテーブルを正規化する ステップ９０２の間、ルックアップテーブル整合部７２
６は関係のないテーブルを識別して捨てる。このステッ
プを行っている間の目標は、ルックアップテーブル７１
８、７２０をその最小の大きさにまで圧縮してルックア
ップテーブル７１８、７２０の中のサブテーブルがそれ
ぞれ少くとも１つの関係のあるエントリを持つようにす
ることである。ステップ９０２でこの目標を達成するこ
とにより、ルックアップテーブル整合部７２６は、ステ
ップ９０６で入力用のルックアップテーブル７１８と７
２０をエントリ毎に整合、つまり対応させることができ
る。 【０１４０】ステップ９０２を行うに際し、ルックアッ
プテーブル整合部７２６は型エントリを無視する。ルッ
クアップテーブル整合部７２６は、変数エントリだけが
デバッグ情報の修正を必要とするので、（ＳＶＡＲ、Ｄ
ＶＡＲ及びＦＰＡＲＡＭのような）変数エントリにだけ
注意を払う。 【０１４１】オブジェクトコードファイル１１８はトラ
ンスレータ３０２により作られたテンポラリデータにつ
いての多数のエントリを含んでいる。これらテンポラリ
データができるために、コンパイラデバッグデータ構造
５１６に入っているコンパイラデバッグ情報１２６のブ
ロック構造が変化する。例えば、トランスレータルック
アップテーブル７２０の中では空になっているテーブル
が、コンパイラルックアップテーブル７１８中では空で
はなくなっていることがある。 【０１４２】それ故、ステップ９０２の間、ルックアッ
プテーブル整合部７２６は、トランスレータ３０２が作
り出したテンポラリデータを表わすＤＶＡＲを無視する
。このようなテンポラリデータＤＶＡＲはその名前で識
別することができる。本発明の好適実施例では、ＤＶＡ
Ｒテンポラリデータは文字列「＿＿［Ａ−Ｚ］」（すな
わち、２つのアンダースコア文字の次に大文字のアルフ
ァベットが続くもの）で始まる名前を持っているとされ
ている。 【０１４３】本発明の好適実施例では、ルックアップテ
ーブル整合部７２６はステップ９０２を行うのに表１２
に擬似コードで示すアルゴリズムを使用している。 【０１４４】 　　　　　　　　　　　　　〈表−１２〉ｆｏｒ　ｔａ
ｂｌｅ＿ｒｏｏｔ．ｄｅｐｔｈ−ｆｉｒｓｔ−ｓｅａｒ
ｃｈ（）　中の各テーブル　ｄｏ　　　　ｉｆ　ｔａｂ
ｌｅ．ｅｍｐｔｙ（）　ｔｈｅｎ　　　　　　　　＃　
　このテーブルを消去する　　　　　　　　このテーブ
ルの全要素を親テーブル中にコピーする　　　　　　　
　このテーブルへの親テーブルからのリンクポインタを
　　　　　　　　　　　　このテーブルのサブテーブル
のリストで置換する　　　　ｅｎｄｉｆ ｅｎｄｆｏｒ 【０１４５】ルックアップテーブル整合部７２６は、テ
ーブルがＳＶＡＲを含まずかつテーブルに入っているＤ
ＶＡＲがトランスレータ３０２で作られたテンポラリデ
ータであれば、テーブルが空であるとみなす。 【０１４６】３．２．２．２　ステップ９０６−深さ優
先の走査を行う ステップ９０６の間、ルックアップテーブル整合部７２
６はトランスレータルックアップテーブル７２０のエン
トリをコンパイラルックアップテーブルのそれに対応す
るエントリと整合させる。ステップ９０６を行うには、
ルックアップテーブル整合部７２６は２つのルックアッ
プテーブル７１８と７２０に対して並列、深さ優先の走
査を行う。 【０１４７】本発明の好適実施例では、ルックアップテ
ーブル整合部７２６はステップ９０６を行うのに表１３
に疑似コードで示したアルゴリズムを使用する。 【０１４８】 　　　　　　　　　　　　　〈表−１３〉ｍａｔｃｈ＿
ｔａｂｌｅｓ　（ｄｔａｂ　＊ｃｐｐ＿ｔａｂ，　ｄｔ
ａｂ　＊ｃｔａｂ）｛ 　　　　ｃｐｐ＿ｔａｂ　と　ｃ＿ｂａｂ　の互に対応
するフィールドを指示する　　　　ｆｏｒ　ｃｐｐ＿ｔ
ａｂ　の各子　ｄｏ　　　　　　　　ｃ＿ｔａｂ　の次
の子を得る　　　　　　　　ｍａｔｃｈｉｎｇ＿ｔａｂ
ｌｅｓ　（ｃｐｐ＿ｔａｂ＿ｃｈｉｌｄ，　ｃ＿ｔａｂ
＿ｃｈｉｌｄ）；　　　　ｅｎｄｆｏｒ ｝ 【０１４９】表１３に示したアルゴリズムは、コンパイ
ラルックアップテーブル７１８とトランスレータルック
アップテーブル７２０の双方において、対応するテーブ
ル（関数やローカルブロック等に対するもの）が正確に
同じ順序で現われるという仮定のもとに動作する。この
仮定はステップ９０２により保証される。 【０１５０】３．２．３　ステップ８１０−調整を行う
ステップ８１０を行うには、ルックアップテーブル調整
部７４４は整合済みトランスレータルックアップテーブ
ル７３４に対しての深さ優先走査を行う。 【０１５１】整合済みトランスレータルックアップテー
ブル７３４だけに対して走査が行われる。整合済みトラ
ンスレータルックアップテーブル７３４の中の各サブテ
ーブルの各エントリを整合済みコンパイラルックアップ
テーブル７３２の中の対応するサブテーブル内で探す。 このようなエントリが整合済みコンパイラルックアップ
テーブル７３２内に存在しなければ、トランスレータル
ックアップテーブル７３４の中のこのエントリに対応す
るＤＮＴＴエントリに削除用の印を付ける。その他の場
合には、整合済みコンパイラルックアップテーブル７３
２からの情報を整合済みトランスレータルックアップテ
ーブル７３４にコピーする。 【０１５２】ルックアップテーブル調整部７４４が整合
ルックアップテーブル７３２と７３４の間で情報をコピ
ーするやり方を次の章で詳細に説明する。 【０１５３】３．２．３．１　ＤＮＴＴフィールド値整
合済みコンパイラルックアップテーブル７３２に対応す
るエントリが見つかると、ルックアップテーブル調整部
７４４は可能な全ての情報を整合済みトランスレータル
ックアップテーブル７３４のエントリにコピーする。 具体的には、ＤＶＡＲ及びＦＰＡＲＡＭのエントリにつ
いては、ルックアップテーブル調整部７４４は、スタッ
クオフセット値及びレジスタフラブ値をコピーする。 【０１５４】ＳＶＡＲエントリについては、ルックアッ
プテーブル調整部７４４は、シンボルロケーション値に
ついての将来の決定用情報を設定し、シンボルオフセッ
ト値、変位値及びロケーション値をコピーする。 【０１５５】ＦＵＮＣエントリについては、ルックアッ
プテーブル調整部７４４は、ｅｎｔｒｙａｄｄｒ値、最
適化フィールド値、ｌｏｗａｄｄｒフィールド値及びｈ
ｉａｄｄｒフィールド値をコピーする。実現の仕方によ
っては、ルックアップテーブル調整部７４４は、これら
フィールドについての決定用情報を設定してもよい。 【０１５６】ＯＢＪＥＣＴ＿ＩＤエントリについては、
ルックアップテーブル調整部７４４はｏｂｊｅｃｔ＿ｉ
ｄｅｎｔフィールド値についての決定用情報を設定する
。 【０１５７】３．２．３．２．　ＳＬＴルックアップテ
ーブル調整部７４４は、対応するＤＮＴＴ＿ＢＥＧＩＮ
／ＤＮＴＴ＿ＥＮＤ対をＳＬＴ＿ＢＥＧＩＮ／ＳＬＴ＿
ＥＮＤ対と整合させる。 ルックアップテーブル調整部７４４はまた、ＭＯＤＵＬ
Ｅ対及びＦＵＮＣＴＩＯＮ対を整合させる。そのように
整合させることができないＳＬＴまたはＤＮＴＴ　ＢＥ
ＧＩＮ／ＥＮＤエントリは、削除の目標である（ただし
下の説明を参照）。 【０１５８】また、ルックアップテーブル調整部７４４
は、ＳＬＴ＿ＣＬＡＳＳ＿ＳＣＯＰＥエントリ及びＳＬ
Ｔ＿ＷＩＴＨエントリ（及びそれに対応するＳＬＴ＿Ｅ
ＮＤ）を挿入し、対応するＤＮＴＴエントリを整合させ
る。コンパイラ１１４はこれらのエントリを出力しない
。それは、それらがトランスレータデバッグ情報３０６
に固有のものであるからである。 【０１５９】また、ルックアップテーブル調整部７４４
は、余分のＳＬＴ＿ＢＥＧＩＮ／ＳＬＴ＿ＥＮＤ対を挿
入して、関数内部のクラス宣言に包まれているＤＮＴＴ
＿ＢＥＧＩＮ／ＤＮＴＴ＿ＥＮＤ対と整合させる。これ
らは決して削除してはならない。 【０１６０】上述の操作を行うには、ルックアップテー
ブル調整部７４４は最初に初期ＳＬＴを設定し、次にＳ
ＬＴを増加する。これら２つのステップについて次の章
で詳細に説明する。 【０１６１】３．２．３．２．１　初期ＳＬＴを設定す
る表６及び表７に示すように、テーブルノードは２つの
ＳＬＴポインタ用フィールドを含んでいる。１つはＳＬ
Ｔ＿ＢＥＧＩＮ（またはＦＵＮＣＴＩＯＮまたはＭＯＤ
ＵＬＥ）へのポインタであり、もう１つはブロックを区
切るＤＮＴＴに対応するＳＬＴ＿ＥＮＤへのポインタで
ある。 【０１６２】これらノードは、整合済みコンパイラルッ
クアップテーブル７３２については正しく設定されるが
、トランスレータルックアップテーブル７３４について
は正しく設定されない。ルックアップテーブル調整部７
４４は、下記のステップを行って整合済みトランスレー
タルックアップテーブル７３４についてのこれらノード
を設定する。 【０１６３】最初に、ルックアップテーブル調整部７４
４は、整合済みトランスレータルックアップテーブル７
３４についての修正のためのＳＬＴのコピーを、整合済
みコンパイラルックアップテーブル７３２から作る。こ
のコピー中のＤＮＴＴ逆方向ポインタはクリアされる。 【０１６４】調整ステップ８１０の間（ルックアップテ
ーブル調整部７４４は、この動作の間は挿入や削除を行
わない）、ルックアップテーブル調整部７４４は、整合
済みコンパイラルックアップテーブル７３２中の対応す
るエントリが指すものと同じオフセットにある対応する
ＳＬＴエントリを指すように、整合済みトランスレータ
ルックアップテーブル７３４を設定する（また、勿論、
これら新しいＳＬＴエントリに対する対応する逆方向ポ
インタを設定する）。 【０１６５】これら２つのステップが終了してからも、
幾つかの未整合ＤＮＴＴ＿ＢＥＧＩＮ／ＤＮＴＴ＿ＥＮ
Ｄ対と、おそらくは幾つかの未整合ＳＬＴ＿ＢＥＧＩＮ
／ＳＬＴ＿ＥＮＤ対が存在することがある。ルックアッ
プテーブル調整部７４４はこれらを削除の目標とする。 【０１６６】また、ルックアップテーブル調整部７４４
は、幾つかのＳＬＴ＿ＢＥＧＩＮ及びＳＬＴ＿ＦＵＮＣ
ＴＩＯＮノードに或る特別の印を設定し、これにより、
後のＳＬＴ増加操作を行う段階で何等かのノードを生成
してそれらのノードの回りに挿入しなければならないこ
とを示す。 【０１６７】３．２．３．２．２　ＳＬＴを増加する上
に記したように、或るＤＮＴＴノードについて、ルック
アップテーブル調整部７４４はＳＬＴエントリを生成す
る。 これらＤＮＴＴノードには以下の２つの種類がある。 【０１６８】第１のものは、ＤＮＴＴ＿ＣＬＡＳＳ＿Ｓ
ＣＯＰＥ及びＤＮＴＴ＿ＷＩＴＨノードである。これら
はクラスのメンバ関数に対するＤＮＴＴ＿ＦＵＮＣノー
ドの前及び後に来る（それらに対応するＤＮＴＴ＿ＥＮ
Ｄもまた関数のＤＮＴＴ＿ＥＮＤを括る）。 【０１６９】第２のものは、特別に印の付いたＤＮＴＴ
＿ＢＥＧＩＮ及びＤＮＴＴ＿ＥＮＤノードである。これ
らは、関数内部のローカルクラス宣言を取り囲むものと
して出力される。これらノードは、普通のＢＥＧＩＮ及
びＥＮＤとしては処理されない（すなわち、これらにつ
いてはテーブルが作られない）。 【０１７０】第１の場合については、ルックアップテー
ブル調整部７４４は、ＤＮＴＴ＿ＦＵＮＣの未使用フィ
ールドに、関数の前のＤＮＴＴ＿ＣＬＡＳＳ＿ＳＣＯＰ
Ｅの有無及び関数の後のＤＮＴＴ＿ＷＩＴＨの有無につ
いて１ビットづつ、合計２ビットの印を付ける。 【０１７１】第２の場合については簡単な印を付けるこ
とは不可能である。各々がＤＮＴＴ＿ＦＵＮＣＴＩＯＮ
／ＤＮＴＴ＿ＥＮＤ対の内部（すなわち、ローカルブロ
ックの内側で宣言されたクラス）ではなく、ＤＮＴＴ＿
ＢＥＧＩＮ／ＤＮＴＴ＿ＥＮＤ対の内部に現われる、任
意の個数のＢＥＧＩＮ／ＥＮＤ対が存在できる。 【０１７２】模造ブロック（ｆａｋｅ　ｂｌｏｃｋ）と
いう概念は、これらの状況を取扱うのに使用される。 【０１７３】模造ブロックは「現実のブロック」と同じ
であるが、テーブル構築ステップ８０２の間、ルックア
ップテーブル構築部７１０、７１２が印の付いたＢＥＧ
ＩＮ（またはこのような印の付いたＢＥＧＩＮに対応す
るＥＮＤ）を見つけたとき、ルックアップテーブル構築
部が別個のテーブルスタックにプッシュダウンしたりポ
ップアップする点だけが違う。最後のこのようなエント
リがポップアップされると、サブトリー全体が直ぐ外側
の「現実の」テーブルに取付けられる。 【０１７４】ＳＬＴを埋め盡すには、ルックアップテー
ブル調整部７４４は、ＳＬＴを走査してこれを１エント
リづつ新しいコピーに転写する。ルックアップテーブル
調整部７４４は、役に立たないＳＬＴエントリ（例えば
、ＤＮＴＴ＿ＳＲＣＦＩＬＥに対応しなかったＳＬＴ＿
ＳＲＣＦＩＬＥ）を捨て、上述のように幾つかのＳＬＴ
エントリを挿入する。 【０１７５】ルックアップテーブル調整部７４４は、加
除されたＳＬＴエントリの数のカウンタを保持している
。ＳＬＴ＿ＳＰＥＣＩＡＬが現われると、ルックアップ
テーブル調整部７４４は、ＤＮＴＴを逆方向に指示する
そのＤＮＴＴＰＯＩＮＴＥＲに従い、このオフセットカ
ウンタをそのＳＬＴＰＯＩＮＴＥＲに加える。 【０１７６】ＳＬＴへの各エントリについて、ルックア
ップテーブル調整部７４４は次の処置を取る。 【０１７７】ＳＬＴ＿ＮＯＲＭＡＬエントリについては
、ルックアップテーブル調整部７４４は、これらを整合
済みトランスレータルックアップテーブルにコピーし、
両インデクスを１だけインクリメントさせる。 【０１７８】ＳＬＴ＿ＳＲＣＦＩＬＥエントリについて
は、ＤＮＴＴ逆方向ポインタがＤＮＴＴ＿ＮＴＬであれ
ば、ルックアップテーブル調整部７４４はこのＳＬＴ＿
ＳＲＣＦＩＬＥエントリを捨て、オフセットカウンタを
デクリメントさせる。その他の場合には、ルックアップ
テーブル調整部７４４はＤＮＴＴ逆方向ポインタを整合
済みトランスレータルックアップテーブル７３４にコピ
ーする（そして逆方向ポインタにより指示されているＤ
ＮＴＴエントリを調節する）。 【０１７９】ＳＬＴ＿ＢＥＧＩＮエントリについては、
ＤＮＴＴ逆方向ポインタがＤＮＴＴ＿ＮＩＬであれば、
ルックアップテーブル調整部７４４はこのＳＬＴ＿ＢＥ
ＧＩＮエントリを捨て、オフセットカウンタをデクリメ
ントさせる。 【０１８０】その他の場合には、ルックアップテーブル
調整部７４４はノードをコピーする。ルックアップテー
ブル調整部７４４は次にこのノードにより指示されてい
るＤＮＴＴ＿ＢＥＧＩＮを調べる。調整ステップ８１０
の間、ルックアップテーブル調整部７４４は模造ブロッ
クテーブルのトリーのコピーをＤＮＴＴ＿ＢＥＧＩＮの
終りの未使用のパディングワードに格納する。このノー
ドが０でなければ、ルックアップテーブル調整部７４４
は模造ブロックトリーの深さ優先の走査を行う。 【０１８１】模造ブロックトリーの深さ優先の走査を行
いながら、ルックアップテーブル調整部７４４は、下降
途中で出逢う各テーブルについてＳＬＴ＿ＢＥＧＩＮを
作る。これらノードについてのＤＮＴＴポインタは模造
ブロックノードに格納され、ＤＮＴＴからＳＬＴへの前
進及び後退リンクを設定するのに使用される。ルックア
ップテーブル調整部７４４は次にオフセットカウンタを
インクリメントさせる。 【０１８２】ルックアップテーブル調整部７４４はまた
、上昇の途中で各テーブルについてのＳＬＴ＿ＥＮＤを
作り、これに同様にパッチを当て、オフセットカウンタ
をインクリメントさせる。 【０１８３】ＳＬＴ＿ＦＵＮＣＴＩＯＮエントリについ
ては、ルックアップテーブル調整部７４４は、これらの
ＳＬＴエントリに対応するＤＮＴ＿ＦＵＮＣＴＩＯＮエ
ントリを追跡して位置を突きとめる。ルックアップテー
ブル調整部７４４は、ＤＮＴＴ＿ＣＬＡＳＳ＿ＳＣＯＰ
Ｅ及び／またはＤＮＴＴ＿ＷＩＴＨの存在を示すフラグ
がないかどうかチェックする。 【０１８４】クラススコープに関するフラグが設定され
ていれば、ルックアップテーブル調整部７４４はＳＬＴ
＿ＣＬＡＳＳ＿ＳＣＯＰＥを生成してオフセットカウン
タをインクリメントさせる。ルックアップテーブル調整
部７４４はＤＮＴＴ＿ＦＵＮＣＴＩＯＮから後向きに探
し、ＤＮＴＴ＿ＣＬＡＳＳ＿ＳＣＯＰＥの位置を突きと
めてこれを整合させる。 【０１８５】次に、ルックアップテーブル調整部７４４
は、ＳＬＴ＿ＦＵＮＣＴＩＯＮノード全体をコピーし、
ＤＮＴＴ＿ＦＵＮＣＴＩＯＮのＳＬＴポインタを、オフ
セットカウンタにより調節する。 【０１８６】ＤＮＴＴ＿ＷＩＴＨフラグが設定されてい
れば、ルックアップテーブル構築部７４４は、ＳＬＴ＿
ＷＩＴＨを生成し、同様にＤＮＴＴ＿ＷＩＴＨを捜し出
して前進・後退ポインタを設定する。 【０１８７】最後に、ルックアップテーブル構築部７４
４は模造ブロックがないかどうかチェックし、ＤＮＴＴ
＿ＢＥＧＩＮに対するのと同じ手続を取る。 【０１８８】ＳＬＴ＿ＥＮＤエントリについては、ＤＮ
ＴＴ逆方向ポインタがＤＮＴＴ＿ＮＩＬであれば、ルッ
クアップテーブル構築部７４４はこのエントリを捨て、
オフセットカウンタをデクリメントさせる。そうでない
場合には、ルックアップテーブル構築部７４４は、（そ
れに対応したＤＮＴＴ＿ＥＮＤを見出しそのｂｅｇｉｎ
ｓｃｏｐｅフィールドを調べることにより）そのスコー
プを開始した対応するＤＮＴＴをチェックする。対応し
たＤＮＴＴがＤＮＴＴ＿ＦＵＮＣＴＩＯＮであってかつ
ｃｌａｓｓ＿ｓｃｏｐｅまたはｗｉｔｈフラグがセット
されていれば、ルックアップテーブル構築部７４４がＳ
ＬＴ＿ＥＮＤを生成して既に作られているＳＬＴ＿ＣＬ
ＡＳＳ＿ＳＣＯＰＥまたはＳＬＴ＿ＷＩＴＨを整合させ
、これに従ってポインタとオフセットカウンタにパッチ
を当てる。ルックアップテーブル構築部７４４はＳＬＴ
＿ＦＵＮＣＴＩＯＮに対するのと同じ手法を取る。すな
わち、クラススコープに対してＳＬＴ＿ＥＮＤを挿入し
、このＥＮＤをコピーし、ｗｉｔｈに対してＳＬＴ＿Ｅ
ＮＤを挿入する。 【０１８９】ＳＬＴ＿ＭＯＤＵＬＥエントリについては
、ルックアップテーブル調整部７４４はエントリを完全
にコピーする。それは１つのものしか存在しないからで
ある。 【０１９０】上の処置が完了した後には、要素ごとにＬ
ＮＴＴに正しく整合つまり対応している新しいＳＬＴが
存在する。また、この新しいＳＬＴには使用されていな
いエントリは含まれていない。 【０１９１】３．２．３．３　ＤＮＴＴ＿ＳＲＣＦＩＬ
ＥとＳＬＴ＿ＳＲＣＦＩＬＥを整合させる ＳＲＣＦＩＬＥエントリは、デバッグ情報構成の中で最
も体系的でない部分である。ＳＣＲＦＩＬＥをどこに出
力するかについては、コンパイラが異れば、その方針が
異なる。 【０１９２】これに加えて、ある侵すことのできないＳ
ＲＣＦＩＬＥエントリが存在する（例えば、ＦＵＮＣＴ
ＩＯＮエントリの直前にあるＳＣＲＦＩＬＥエントリ）
。 【０１９３】整合ルックアップテーブル７３２、７３４
中の各ノード及びテーブルは、そのノードの直前にある
ＳＣＲＦＩＬＥエントリへのポインタを有している。こ
れに加えて、各テーブルノードは、そのテーブルのＤＮ
ＴＴ＿ＥＮＤの直前のＳＲＣＦＩＬＥへのポインタを有
している。 【０１９４】ルックアップテーブル調整部７４４はこの
問題点を解決するために発見的方法を利用している。 【０１９５】調整ステップ８１０の間にトリーを走査す
ると、ルックアップテーブル調整部７４４はＳＲＣＦＩ
ＬＥエントリを飛越す（これらのエントリは帳簿付け及
びデバッグのためだけに整合済みトランスレータルック
アップテーブル７３４中に存在する）。その代り、ルッ
クアップテーブル調整部７４４はテーブルに出会う毎に
下記アルゴリズムを使用する。 【０１９６】ステップ１：ルックアップテーブル調整部
７４４は、対応するテーブルのＳＲＣＦＩＬＥエントリ
を使用して、ブロックのＢＥＧＩＮに対応するＳＲＣＦ
ＩＬＥエントリを決定する（ｆｉｘ　ｕｐ）。 【０１９７】ステップ２：ルックアップテーブル調整部
７４４は、上述のように整合済みトランスレータルック
アップテーブル７３４のサブテーブルの深さ優先の走査
を行う。 【０１９８】ステップ３：ルックアップテーブル調整部
７４４はブロックのＥＮＤに対応するＳＲＣＦＩＬＥエ
ントリを決定する。 【０１９９】ステップ４：整合済みトランスレータルッ
クアップテーブル７３４の各エントリについて、ルック
アップテーブル調整部７４４は、このノードにより指示
されているＳＲＣＦＩＬＥエントリを決定する。 【０２００】ルックアップテーブル調整部７４４は、Ｆ
ＵＮＣＴＩＯＮまたはＢＥＧＩＮのノードに出逢うと、
最後に見たＳＲＣＦＩＬＥをＮＵＬＬにリセットする。 これは、ＳＲＣＦＩＬＥが上記のアルゴリズムのステッ
プ１により修正されるために可能である。 【０２０１】上の４ステップアルゴリズムが終了した後
、ＦＵＮＣＴＩＯＮに対応する各ＳＲＣＦＩＬＥが決定
される。他のＳＲＣＦＩＬＥは、関数の内部で変化する
もの以外は重要ではなく、これらはステップ３及びステ
ップ４でルックアップテーブル調整部により処理される
。 【０２０２】３．２．４．　ステップ８１４−整頓する
ステップ８１４の間、ルックアップテーブル調整部７４
４は、削除用の印が付いているエントリを削除すること
により名前及び型テーブル（Ｎａｍｅ　ａｎｄＴｙｐｅ
　Ｔａｂｌｅ，　ＮＴＴ）を整頓する。ルックアップテ
ーブル調整部７４４は、このステップの間、ＬＮＴＴと
ＧＮＴＴの内部の相互リンクがあるため注意を払わなけ
ればならない。 【０２０３】ルックアップテーブル調整部７４４は、問
題となっているエントリを、その種類フィールドをＫ＿
ＮＩＬに設定することにより削除し、または無効にする
。エントリがＤＮＴＴ＿ＢＬＯＣＫの１個分より長けれ
ば、２番目以降のブロックも加工されていないＤＮＴＴ
＿ＢＬＯＣＫとして処理され、その種類フィールドはＫ
＿ＮＩＬに設定され、その延長フラグは０にリセットさ
れる（こうしてこのエントリを幾つかの隣接したＫ＿Ｎ
ＩＬブロックのように見せる）。 【０２０４】整頓を行うには、ルックアップテーブル調
整部７４４は、ＤＮＴＴに対して最後の走査を行い、「
特別に印が付けられた」ＤＮＴＴエントリを全て探し、
それらを上述のように無効にする。 【０２０５】３．３　出力オブジェクトファイルインタ
ーフェース 図５に示すように、出力オブジェクトファイルインタフ
ェース５１４は、新しいオブジェクトコード３１６を作
り、新しいオブジェクトコード３１６にオブジェクトコ
ード１２４及びトランスレータデバッグ情報３０６とコ
ンパイラデバック情報１２６の組合せを格納する。 【０２０６】出力オブジェクトファイルインターフェー
ス５１４のフローチャートを図１０に示す。出力オブジ
ェクトファイルインターフェース５１４の動作を今度は
図５、図７及び図１０を参照して説明する。 【０２０７】ステップ１００２で、出力オブジェクトフ
ァイルインターフェース５１４は最終デバッグ情報を含
むオブジェクトコード３１６用のファイルを書き込み用
に生成する。 【０２０８】ステップ１００６で、出力オブジェクトフ
ァイルインターフェース５１４はオブジェクトファイル
１２４のヘッダのためのスペースをオブジェクトコード
３１６用のファイルに残す。 【０２０９】ステップ１０１０で、出力オブジェクトフ
ァイルインターフェース５１４は、オブジェクトコード
ファイル１１８、マージ済みルックアップテーブル５２
８及びポータブル出力決定用情報５３０からの情報を、
最終デバッグ情報を含むオブジェクトコード３１６用の
ファイルに書込む。出力オブジェクトファイルインター
フェース５１４は、この情報をこのファイルに次の順序
で書込む。 【０２１０】最初に、出力オブジェクトファイルインタ
ーフェース５１４は、テキストを、次にデータを、次に
もし存在すれば、Ｐａｓｃａｌインターフェースをこの
ファイルに書込む。 【０２１１】出力オブジェクトファイルインターフェー
ス５１４は次に、シンボルテーブルを最終デバッグ情報
を含むオブジェクトファイル３１６に書込む。これはシ
ンボルテーブルをオブジェクトコードファイル１１８か
らこのファイル３１６にコピーすることにより行われる
。次に、シンボルが関数ａｄｄ＿ｓｙｍｂｏｌ（）を使
用して付加される（表４及び表５）。最後に、シンボル
テーブルのサイズをオブジェクトファイルのヘッダ中で
調節する。 【０２１２】出力オブジェクトファイルインターフェー
ス５１４は次にＳｕｐｓｙｍ、テキスト再配置レコード
及びデータ再配置レコードをファイル３１６に書込む。 【０２１３】出力オブジェクトファイルインターフェー
ス５１４は次に、延長ヘッダ、デバッグヘッダ、ＧＮＴ
Ｔ、ＬＮＴＴ、ＳＬＴ及びＶＴ（及びもしあればＸＴ）
及び別の延長部分から成るデバッグ情報をファイル３１
６に書込む。また、延長ヘッダのオフセット及びサイズ
がオブジェクトファイルヘッダに記録される。 【０２１４】ステップ１０１４で、出力オブジェクトフ
ァイルインターフェース５１４は、オブジェクトファイ
ルヘッダを最終デバッグ情報を含むファイル３１６のオ
フセット０の位置に書込む。 【０２１５】本発明の好適実施例２２８では、出力オブ
ジェクトファイルインターフェース５１４はクラスの形
態で実現されている。これらクラスのインスタンスはオ
ブジェクトコード及びデバッグ情報が入っているファイ
ルを読み書きするのに使用される。 【０２１６】出力オブジェクトファイルインターフェー
ス５１４のクラスは、入力オブジェクトファイルインタ
ーフェース５０２、５０４についてのクラスと同じであ
る。これらのクラスを構成するクラス、データ構造及び
関数は表２、表３、表４及び表５に示してある。 【０２１７】出力オブジェクトファイルインターフェー
ス５１４の動作は、関数を表２、表３、表４及び表５で
示したクラスから呼出すことにより行われる。例えば、
ＨＰ９０００シリーズ３００コンピュータプラットフォ
ーム２０２上で動作するときは、関数Ｗｒｉｔｅ＿ｄｅ
ｂｕｇ＿ｉｎｆｏ（）を使用してデバッグ情報７５０を
ファイル３１６に書込む。また、関数ｃｏｐｙ（）を使
用してオブジェクトコード１２４をファイル３１６に書
込む。 【０２１８】４．０　デバッガ 図１１は、本発明の好適実施例２２８のデバッガ３２０
の構造図／機能フローチャートを示す。図１１で、端末
２１８及びユーザ１１１８以外は、長方形はソフトウェ
アモジュール／プロセスを表わし、長円形はソフトウェ
アモジュール／プロセスの入力及び出力を表わす。 【０２１９】図１１に示すように、デバッガ３２０は２
つのモジュール、すなわちプリプロセッサ１１０４と主
デバッガ１１１２を含んでいる。 【０２２０】プリプロセッサ１１０４は、実行可能ファ
イル３５０（実行可能ファイル３５０はオブジェクトコ
ード３１６中の最終デバッグ情報を含んでいる）を受取
り、前処理されたデバッグ情報１１０８を発生する。前
処理されたデバッグ情報１１０８は、プリプロセッサ１
１０４が重複した情報を除去し、情報の各部分間のポイ
ンタを決定し（ｆｉｘ　ｕｐ）、あるデータを特別のテ
ーブル（図１１には図示してない）に集めてこれを主デ
バッガ１１１２が使用するように、前処理されたデバッ
グ情報１１０８に追加することを除いては、オブジェク
トコード３１６中の最終デバッグ情報と同じである。 【０２２１】具体的には、プリプロセッサ１１０４は、
ソースファイルデスクリプタテーブル、手続デスクリプ
タテーブル、クラスデスクリプタテーブル及びアドレス
エイリアステーブル（図１１には示してない）を生成す
る。 【０２２２】ソースファイルデスクリプタテーブルには
、生成されたコードのどの部分をソースコード１０２に
マップするかについての記述が入っている。ソースファ
イルデスクリプタテーブルには、ソースファイルデスク
リプタエントリが入っている。ソースファイルデスクリ
プタエントリには、とりわけ、ファイルデスクリプタに
よりカバーされるコードアドレスの範囲を示す開始及び
終りのアドレスと、それからコードを生成したソースフ
ァイルの名前が入っている。主デバッグ１１１２が正し
く動作するには、ファイルデスクリプタにより記述され
るアドレス範囲が減少しないソース行レンジをカバーし
なければならない。このことは１つのソースファイルが
それに関連する幾つかのファイルデスクリプタを備える
ことができることを意味している。 【０２２３】手続デスクリプタテーブルにはデバッグ可
能な手続及び／またはプログラム１０２の中の関数の全
ての記述が入っている。プリプロセッサ１１０４により
初期設定されるＣ＋＋特有の情報は、関数がプログラム
１０２のどこかで二重になっているか、オーバーロード
されているか、メンバ関数であるか（もしそうなら、ど
のクラスのメンバか）、コンストラクタであるか、デス
トラクタであるか、静的であるか、仮想であるか、純仮
想（ｐｕｒｅ　ｖｉｒｔｕａｌ）であるか、定数である
か、インライン展開されているか及び／または演算子関
数であるかを示す。 【０２２４】クラスデスクリプタテーブルは、クラスが
定義されているソースコード１０２中のソース行の範囲
を指示することにより各クラスのスコープを記述する。 【０２２５】アドレスエイリアステーブルは、ソースコ
ード１０２の単一の部分から発生されたオブジェクトコ
ード１２４の中の複数のコード部分がもしあればそれを
記述する。 【０２２６】主デバッガ１１１２は、前処理されたデバ
ッグ情報１１０８を受取る。端末２１８を介して主デバ
ッガ１１１２と連絡するユーザ１１１８の指示のもとに
、主デバッガ１１１２は、ユーザ１１１８がソースコー
ド１０２の誤りを突きとめて修正するのを、前処理され
たデバッグ情報１１０８を使用して支援する。 【０２２７】具体的には、主デバッガ１１１２は、前処
理されたデバッグ情報１１０８を使用して、とりわけ、
ソースコード１０２を表示し、コンパイラ１１４が発生
したソースコード１０２のアセンブリコードへの翻訳を
表示し、ソースコード１０２上での実行のフローを制御
したり変更したりし、変数の型を表示し、変数の値を観
察したり設定する。 【０２２８】デバッガ３２０の構造及び動作は従来のデ
バッガ１２２のものと同じである。しかし、本発明の好
適実施例２２８のデバッガ３２０は、オブジェクトコー
ド３１６中の最終デバッグ情報、すなわちコンパイラデ
バッグ情報１２６とトランスレータデバッグ情報３０２
を組み合わせたものの中に入っている追加情報を活用す
るという別の修正された特徴を有しているという点で、
従来のデバッガ１２２に比べて改良されている。 【０２２９】本発明の好適実施例２２８では、デバッガ
３２０は、オブジェクトコード３１６中の最終デバッグ
情報に入っているＣ＋＋関連情報を活用する多数の修正
された且つ追加的特徴を有している。 【０２３０】例えば、本発明の好適実施例２２８のデバ
ッガ３２０は、従来のデバッガ１２２では利用できなか
った別の関数の型情報を表示することができる。適用可
能なとき、この追加情報は、特定の関数が、インライン
展開される、オーバーロードされる、静的である、定数
である、または仮想であると宣言されているか否か、ま
た、関数がメンバ関数、演算子関数、コンストラクタ、
またはデストラクタとして宣言されているか否かを示す
。オブジェクトコード３１６中の最終デバッグ情報はま
た、デバッガ３２０に、ソースコード１０２で宣言され
ているが定義を与えられていない関数についての型情報
を表示できるようにする。 【０２３１】デバッガ３２０は、デバッグ情報１１０８
を使用してＣ＋＋の匿名の共用体（ａｎｏｎｙｍｏｕｓ
　ｕｎｉｏｎ）の特徴についての備えも持っている。デ
バッグ情報１１０８は、各匿名の共用体メンバを２つの
形態で効果的に指定する。１つの形態では、匿名の共用
体メンバをあたかもそれが匿名の共用体の外にあるかの
ように指定する。これによりユーザ１１１８は、匿名の
共用体メンバを個々の変数として観察し、また修正する
ことができる。 【０２３２】もう１つの形態は、匿名の共用体メンバを
匿名の共用体のメンバとして指定することである。これ
によりユーザ１１１８は、匿名の共用体についての型及
びデータ情報を全体的に観察することができる。 【０２３３】所与の匿名の共用体の全てのメンバは、オ
ブジェクトコード３１６中の最終デバッグ情報中では構
造体のリンク付きリストとして表わされ、そのリストの
各ノードがそのメンバについての情報を指定し且つ匿名
の共用体の外則のその形態のメンバへのポインタを含ん
でいる。例えば、３つのメンバを有するローカルな匿名
の共用体は、これら３つのメンバが匿名の共用体の一部
でなかった場合と同じになるデバッグ情報を有する。そ
れで、匿名共用体の追加デバッグ情報は、それぞれこれ
ら３つのメンバに対するデバッグ情報を指示する３つの
構造体のリンク付きリストを所持する。 【０２３４】デバッガ３２０はまた、クラス内部で定義
された列挙型への備えも持っている。この特徴は、匿名
の共用体に対するのと同じ仕方で実現される。各列挙型
のメンバは２つの形態で表わされる。１つの形態では、
特定の列挙型について宣言された列挙型メンバのリスト
の一部として表される。第２の形態では、各列挙型メン
バは、それがあたかもそれが見つかったクラスの個別メ
ンバであるかのように表わされる。第１の形によりユー
ザ１１１８は、それがどのクラスで見つかるかを指定す
るという限定だけで各列挙型メンバを個別に使用するこ
とができる。 【０２３５】デバッガ３２０はまた、ソースコード１０
２の所与の部分に結び付いた複数の同一コード部分につ
いての備えも持っている。 【０２３６】例えば、Ｃ＋＋では、ソースコード１０２
のある特定のソースファイル中で定義されたメンバ関数
をソースコード１０２の他のソースファイルにインクル
ードすることができる。 【０２３７】このメンバ関数は、ソースコード１０２中
では１つしか存在しないが、トランスレータ１０６がこ
れを翻訳してコンパイラ１１４かコンパイルするための
中間ソースコード１１０になったときには複数箇所に対
応したコードができている。。すると、コンパイラ１１
４により作られるところの、オブジェクトコード１２４
及びコンパイラデバッグ情報１２６を含むオブジェクト
コードファイル１１８中では、この同じメンバ関数に対
応する複数のコード部分が含まれる。 【０２３８】プリプロセッサ１１０４は、これら複数の
コード部分の各々についてのアドレス範囲を、オブジェ
クトコード３１６中の最終デバッグ情報から集めてアド
レスエイリアステーブルに入れ、前処理されたデバッグ
情報１１０８の中のこのテーブルをデバッガ１１１２に
渡す。アドレスエイリアステーブル内の各エントリは、
１つのコード部分の先頭と最後のアドレスとそのエイリ
アスであるテーブル内の他の全てのコード部分エントリ
を示す情報とを含んでいる。 【０２３９】デバッガ１１１２がコードアドレスに関係
する動作を行うと、このアドレスエイリアステーブルを
参照して、この所与のコードアドレスのエイリアスであ
る個々のアドレスを全て発見することができる。コード
アドレスがアドレスエイリアステーブル内のあるエント
リのアドレス範囲内に入っていれば、デバッガ１１１２
は、このエントリの開始アドレスからこの所与のアドレ
スまでのオフセットを計算する。次いで、計算されたオ
フセット値をコード部分の各々のエイリアスの開始アド
レスに加えることにより、所与のコードアドレスのエイ
リアスであるアドレスの集合を計算で求めることができ
る。 【０２４０】また、デバッガ３２０はクラススコープへ
の備えも持っている。ユーザ１１１８は、Ｃ＋＋構文に
従ってクラスを明示的に宣言することにより、コマンド
式中で使用するクラスメンバを指定することができる。 例えば、メンバはＡ：：Ｂとして与えることができる。 ここで、Ａはクラスであり、ＢはクラスＡのメンバであ
る。クラス及び、必要な場合は、クラスオブジェクトが
、現在観察しているロケーションにより暗黙のうちに決
まるのであれば、ユーザ１１１８はクラス名を明示的に
宣言する必要はない。クラススコープがそれを暗黙のう
ちに決めるからである。 【０２４１】これらの場合には、ソースコード１０２中
で観察されているロケーションは、ファイル記述テーブ
ルから決まるコードアドレスにマッピングされる。この
コードアドレスは、手続デスクリプタテーブルから決ま
る関数にマッピングされる。この関数は、デバッガ３２
０がクラス自身、その基底クラス及びそのスコープに関
して必要とする全ての情報を指すクラスデスクリプタテ
ーブル内のクラスにマッピングされる。 【０２４２】デバッガ３２０はまた、クラスメンバへの
ポインタを取り扱うに当たっては、このようなポインタ
に割当てられた値及びこのようなポインタをプリントす
ることにより表示される値が、数値の値ではなくクラス
識別子及びメンバ識別子それ自身を使用するようにする
。例えば、Ｐと呼ばれるクラスメンバへのあるポインタ
の値をプリントすると、 Ｐ＝＆Ｍ：：Ｎ が表示される。ここでＭはクラスであり、ＮはクラスＭ
のメンバである。内部的に、ポインタは、数値定数のオ
フセットとして表わされるが、追加クラスデバッグ情報
を用いて、デバッガ１１１２は、どのクラスメンバにこ
の数値が対応するかを判定し、この数値の代りに実際の
識別子をプリントするかを決定することができる。 【０２４３】デバッガ３２０はまた、インスタンスブレ
ークポイントを取り扱う。すなわち、デバッガ３２０は
、ユーザ１１１８がメンバ関数でブレークポイントを設
定して、関数が特定のオブジェクトに対して呼出された
場合にのみこのブレークポイントが認識されるようにす
ることができる。 【０２４４】デバッガ３２０はこの動作を、オブジェク
トのアドレスをブレークポイント自身と共に保存するこ
とにより行う。ブレークポイントに行き当たると、デバ
ッガ３２０は、前処理されたデバッグ情報１１０８の助
けを借りて、それについてこの関数が呼出されたオブジ
ェクトのアドレスを判定し、このアドレスを格納されて
いるアドレスと比較し、両者が等しい場合に限りデバッ
ガの実行をサスペンドする。それ以外の場合には、デバ
ッガはそのまま動作を続け、ユーザ１１１８から見て、
実行の中止は起こらない。 【０２４５】デバッガはまた、オブジェクトが定義され
ている範囲を離れて実行が進行しようとしたとき、イン
スタンスブレークポイントを自動的に削除するための備
えを持っている。 【０２４６】オブジェクトのスコープを決定することが
できる場合には、デバッガ３２０はまた、トリガブレー
クポイントと呼ばれる別のブレークポイントを、オブジ
ェクトコード内の、実行がこのスコープを離れようとす
る地点に設定する。このブレークポイントに行き当ると
、それが関連しているインスタンスブレークポイントと
このトリガブレークポイント自身の双方が取除かれて実
行が継続する。 【０２４７】デバッガ３２０はまた、クラスブレークポ
イントも取り扱う。オブジェクトコード３１６中の最終
デバッグ情報は所与のクラスの及びそのクラスの基底ク
ラスのメンバ関数を示すので、デバッガ３２０を使えば
、ユーザ１１１８はただ１つのコマンドを使うだけで、
１つの特定のクラスの全てのメンバ関数に関するブレー
クポイントを設定することができる。このクラスブレー
クポイントは、クラスのどんなメンバ関数が呼出された
ときでもオブジェクトコードの実行をサスペンドさせる
。 【０２４８】また、デバッガ３２０を使うことにより、
ユーザ１１１８はソースコード１０２中のあるロケーシ
ョンを見たりあるいはそこにブレークポイントを設定し
たいとき、クラス名を指定することによりソースコード
１０２の中の当該ロケーションを指定することができる
。例えば、ユーザ１１８がクラスＣのメンバである関数
ｆを見たい場合、このロケーションを、観察コマンドの
引数としてＣ：：ｆとして指定することができる。デバ
ッガ３２０は、この動作を、クラスデスクリプタテーブ
ルを参照して現在のスコープ中で見える与えられた名前
を使ってクラスを判定することにより行う。デバッガ３
２０は次に、手続デスクリプタテーブルを参照し、その
デスクリプタが以前にクラスデスクリプタテーブルの中
で突き止められたエントリを逆方向に参照するところの
、与えられた名前を持つ関数を探す。 【０２４９】デバッガ３２０はまた、オーバーロード関
数の任意の集合についての操作をグループとして取り扱
う。ユーザ１１１８は、特定の名前を持つオーバーロー
ド関数の型情報を、もし必要ならばクラス名を限定する
ことにより、プリントするように、デバッガ３２０に要
求することができる。同様に、ユーザ１１１８は、特定
の名前を持つ全てのオーバーロード関数に対して、また
必要ならば関数のクラス名を特定のものに限定して、ブ
レークポイントを設定することもできる。デバッガ３２
０は、プリプロセッサ１１０４がオブジェクトコード３
１６中の最終デバッグ情報から作り出した手続デスクリ
プタテーブルに現われるオーバーロード関数に関する情
報を使用する。 【０２５０】なお、本願の開示の一部は著作権保護を受
けるべき資料（具体的には表などに示された各種のコー
ド）を含んでいる。著作権者は、それが特許庁の包袋ま
たは記録に現われている限り、何人による特許開示の複
写にも異議を唱えるものではないが、それ以外の場合に
ついては全ての著作権を留保する。 【０２５１】 【効果】以上詳細に説明したように、本発明によれば、
トランスレータを使って一旦翻訳した後コンパイルする
タイプの言語でかかれたコードのシンボリックデバッグ
を、このようなトランスレータを解さないコンパイラ言
語で書かれたコードの場合と同じ様に行うことができる
ようになる。

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

【符号の説明】

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

Claims (1)

【特許請求の範囲】
1. 【請求項１】以下の（Ａ）ないし（Ｃ）を含み、トラン
   スレータベースのソフトウエアコンパイラでの使用に適
   合するように、意味のあるソースコードのシンボリック
   デバッグ情報を生成するシステム： （Ａ）ソースコードについての第１デバッグ情報を生成
   する第１手段； （Ｂ）以下の（ａ）ないし（ｃ）を含む第２手段：（ａ
   ）ソースコードに対するオブジェクトコードを生成する
   手段； （ｂ）ソースコードに対する第２デバッグ情報を生成す
   る手段； （ｃ）前記オブジェクトコードと前記第２デバッグ情報
   を第１オブジェクトファイルにストアする手段；（Ｃ）
   前記第１デバッグ情報と前記第２デバッグ情報をマージ
   してソースコードに対する第３デバッグ情報を形成する
   ：前記第３デバッグ情報は前記ソースコードを完全かつ
   正確に表現する。