JP2001075815A - ソース内蔵型実行可能プログラム生成方法およびローディング方法およびソース内蔵型実行可能プログラム生成プログラムを記録したコンピュータ読み取り可能な記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 ロードモジュールとその作成に必要としたソ
ースデータ、プロジェクト情報等のデータの対応を明確
にし、管理することにある。 【解決手段】 コンパイラ50によりソースデータ100を
コンパイルしてオブジェクトモジュールを生成し格納
し、ソースデータ100及びプロジェクト情報200(コンパ
イラオプション、リンカオプション、生成するロード名
称などのロード作成に必要な情報)を圧縮部60で圧縮し
て圧縮ソース150及び圧縮プロジェクト情報250を取得し
格納し、リンカ58によりオブジェクトモジュールをリン
クしてロードモジュール350を生成すると共に該リンカ5
8により該ロードモジュール350と圧縮ソース150及び圧
縮プロジェクト情報250を一体化し、ソース内蔵型実行
可能プログラム320を生成する。該プログラム320には内
蔵されたロード、ソース及びプロジェクト情報を後に取
り出すときに参照されるヘッダラベル500が付加され
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】ソフトウェアの開発環境で必
要とされる、ロードモジュールとソースデータ、及びそ
のロードモジュールを生成するときに参照したコンパイ
ラオプション、リンカオプションなどのロードモジュー
ルの生成時に必要な情報（プロジェクト情報）を一元管
理する方法に関する。

【０００２】

【従来の技術】ソフトウェアの開発においては、コンパ
イル／リンク作業が１回しか行われないということはな
く、ソースの修正が行われる度にコンパイル／リンク作
業が行われる。そしてその度に同じ複数のソースデータ
を使用したり、同じオプションを指定することが多い。
そのため、ロードモジュールを生成する際は、ソース
名、そのソースの保存場所、コンパイラオプション、生
成するロードモジュールの名称など、コンパイラ／リン
カがロードモジュールを生成するために必要とする情報
を「プロジェクト情報」として予め記録しておき、ロー
ドモジュール、ソースデータとともに管理するのが一般
的である。これらのデータ・情報の管理手段としては、
例えば特開平５−２３３２３３のように、ソース更新日
時、コンパイル／リンク日時などを管理対象とし、ロー
ドモジュール、ソースデータ、プロジェクト単位の情報
をバージョンの誤りなく、一元管理する手段がある。

【０００３】一方、デバッグ時には、デバッグ用オプシ
ョンを付加してソースデータを再コンパイルし、こうし
て作成したデバッグ用ロードモジュールを実行し、デバ
ッグ情報を得ていた。上記の方法で必要なデバッグ情報
を得られない時には、既存ソースデータを修正してデバ
ッグ用ソースデータを作成し、これをコンパイルしてデ
バッグ用ロードモジュールを作成する。これを実行して
デバッグ情報を得ていた。なお、具体的な公知例とし
て、特開平６−１１９１６３には、デバッグ情報取得不
可能なロードモジュールを入力して、デバッグ情報取得
可能なロードモジュールを生成する手段について述べら
れている。また、特開平５−３３４１１９には、モジュ
ールの実行文に中断点を設定してからロードを実行し、
中断時点での配列要素の値を二次元配列で表示する手段
が述べられている。

【０００４】

【発明が解決しようとする課題】ロードモジュールと、
それを生成するために必要となるソースデータ、プロジ
ェクト情報は、別々に管理されているため管理方法が煩
わしい他に、以下のような問題がある。実際のプログラ
ムの開発においては、プログラムの不具合などの調査、
修正のために、同一名でバージョンの異なるロードモジ
ュール、ソースデータ、プロジェクト情報が複数存在す
ることがある。そのため管理方式を誤ると、コンパイル
／リンクしようとしたバージョンと異なるバージョンの
ソースデータを使用してロードモジュールを生成してし
まうことが往々にして起こる。また、デバッグ等の目的
で以前に生成したロードモジュールを調査／修正する際
に、どのバージョンのソースデータをコンパイルして作
成したロードモジュールか、その時どんなコンパイラオ
プションを指定したかがわからないために、ロードモジ
ュールを生成したときの環境の再現に失敗してしまうこ
ともありえる。さらにドキュメント参照時に古いバージ
ョンのドキュメントを参照して、無関係の情報を得てし
まう可能性もある。その結果、誤ったデバッグ情報を取
得してしまうため、適切な調査、修正が行なえず、プロ
グラムの開発／保守期間が長くなってしまうという問題
点がある。つまり従来の技術には、ロードモジュールと
それを生成するために必要となるソースデータ、プロジ
ェクト情報が別々に管理されているために、 人為的なミスによる、開発環境の再現の失敗をす
る。 再生成に時間がかかることによる、正確なデバッグ
情報取得の失敗をする。という問題点がある。本発明の
目的は、上記の問題点の解決のため、ロードモジュール
とその作成に必要としたソースデータ、プロジェクト情
報、及びドキュメント等のデータの対応を明確にし、管
理することにある。

【０００５】なお、前述の従来の技術で述べた特開平５
−２３３２３３は前記問題点の解決策として、各デー
タを関連づける情報ファイルを作成し、さらに、それら
のファイルを関連づける情報を他のファイルに格納し、
管理する手段について述べたものであり、ソース内蔵型
実行可能プログラムの生成を行う本発明とは、その実現
方式を全く異にするものである。

【０００６】また、ソフトウェア製品開発時には、同一
製品に対する提供先ユーザの要求が、各ユーザごとに異
なるのが普通である。そのため既製のプログラムを、ユ
ーザの要望に合わせて仕様を変更する、いわゆるカスタ
マイズを行って提供することがしばしばである。その場
合、少しずつ異なるロード及びソースが、ユーザの数だ
け多数存在することになる。従来はこれらを全て開発者
側で保管・管理していたため、混乱を招く可能性があっ
た。このように従来は、ユーザに提供したロードと、開
発者側で保管しているロードやソースとの１対１の関係
を、正確かつ効率的に管理する手段が考案されていなか
った。発明の他の目的は、ユーザごとにカスタマイズさ
れた多数のロードやソースを有効に管理することにあ
る。

【０００７】一方、本番でのロード実行時に異常が発生
してから、ソースを解析し、デバッグ用ソースを作成
し、これをコンパイルしてデバッグ用ロードを作成し、
このロードを実行する、といった一連のデバッグ作業を
手作業で行っていると、デバッグ情報を取得するまで
に、時間的な隔たりが生じ、その間に誤操作や他の作業
によりマシン環境が変化してしまい、正しいデバッグ情
報を得られないことがしばしばである。また、作成した
デバッグ用ソースは、一度使用した後、時間が経つと何
のためのソースか忘れられたり、あるいはその存在さえ
忘れられてしまうことが多い。仮にソースの作成者自身
が適切に保管していたとしても、その他の開発者はデバ
ッグ用ソースの存在を知らない。そのため、今後同じ異
常が発生したときに、先に作成したデバッグ用ソースが
再利用しにくく、同じデバッグ用ソースをまた作ってし
まうという二度手間が生じることがある。本発明の更に
他の目的は、本番環境下での異常発生時に「デバッグ用
ロード作成→実行」という作業を自動化して迅速・確実
化することであり、かつもう１つの目的は、デバッグ用
ソースの有効利用を図ることである。

【０００８】なお、前述の従来の技術で述べた特開平６
−１１９１６３は、ロードモジュールを直接解析する手
段について述べたものであり、ソース内蔵型実行可能プ
ログラムを生成することを特徴とする本発明とは、その
実現方式を全く異にするものである。また、同じく従来
の技術で述べた特開平５−３３４１１９は、一度配列情
報の出力を指定すると、正常終了時でも常に配列情報を
出力してしまい、その結果出力量が増加したり、処理速
度が劣化するといった問題点が発生する。

【０００９】

【課題を解決するための手段】上記目的を達成するた
め、本発明は、ソース内蔵型実行可能プログラム生成方
法であり、ソースデータをコンパイラによりコンパイル
してオブジェクトモジュールを生成し、ソースデータを
圧縮部で圧縮し圧縮形式のソースデータを生成し、前記
オブジェクトモジュールをリンカによりリンクしてロー
ドモジュールを生成すると共に該リンカにより該ロード
モジュールと前記圧縮形式のソースデータを一体化して
ソース内蔵型実行可能プログラムを生成するようにして
いる。

【００１０】また、プロジェクト情報を圧縮部で圧縮し
圧縮形式のプロジェクト情報を生成し、前記リンカによ
り前記ロードモジュールと前記圧縮形式のソースデータ
と該圧縮形式のプロジェクト情報を一体化してソース内
蔵型実行可能プログラムを生成するようにしている。

【００１１】また、設計／保守ドキュメントを圧縮部で
圧縮し圧縮形式の設計／保守ドキュメントを生成し、前
記リンカにより前記ロードモジュールと該圧縮形式の設
計／保守ドキュメントと前記他の圧縮形式のデータを一
体化してソース内蔵型実行可能プログラムを生成するよ
うにしている。

【００１２】また、デバッグ用ソースを圧縮部で圧縮し
圧縮形式のデバッグ用ソースを生成し、前記リンカによ
り前記ロードモジュールと該圧縮形式のデバッグ用ソー
スと前記他の圧縮形式のデータを一体化してソース内蔵
型実行可能プログラムを生成するようにしている。

【００１３】また、前記圧縮部で圧縮した全ての圧縮形
式のデータを暗号化部で暗号化し、圧縮／暗号化形式の
データを生成し、前記リンカにより前記ロードモジュー
ルと該圧縮／暗号化形式のデータを一体化してソース内
蔵型実行可能プログラムを生成するようにしている。

【００１４】また、ソース内蔵型実行可能プログラム生
成方法により生成されたソース内蔵型実行可能プログラ
ムのメモリ上へのローディング方法であり、記録媒体上
に記録された前記ロードモジュールはメモリ上にローデ
ィングし、該ロードモジュール以外の各データについて
は、データそのものに替わってデータの記録された記録
媒体上におけるデータのアドレス情報だけを取り出して
ローディングするようにしている。

【００１５】また、ソース内蔵型実行可能プログラム生
成プログラムを記録したコンピュータ読み取り可能な記
録媒体であり、ソースデータをコンパイラでコンパイル
し、オブジェクトモジュールを取得しメモリ格納するス
テップと、ソースデータおよびプロジェクト情報を圧縮
部で圧縮し、圧縮形式のソースデータおよび圧縮形式の
プロジェクト情報を取得しメモリ格納するステップと、
前記取得したオブジェクトモジュールをリンカでリンク
しロードモジュールを生成するステップと、前記リンカ
で該生成したロードモジュールと前記取得した圧縮形式
のソースデータおよび圧縮形式のプロジェクト情報を一
体化し、ソース内蔵型実行可能プログラムを生成するス
テップを有するようにしている。

【００１６】

【発明の実施の形態】以下、本発明の実施例を図面を用
いて説明する。図１に、従来形式の実行可能プログラム
のデータ構造、及び作成手順を示す。この場合、コンパ
イラ５０に対して、ソースとコンパイラオプションを直
接に指定、またはプロジェクト情報２００（コンパイラ
オプション、リンカオプション、生成する実行可能プロ
グラム名称などの一連のプログラム生成情報）を指定し
て、コンパイラ５０がソース１００をコンパイルし、オ
ブジェクトを出力する。次にリンカ５５が、コンパイラ
５０が出力したオブジェクトをリンクして実行可能プロ
グラム３００を作成する。この実行可能プログラム３０
０は、ローダ７０がメモリ上にロードすることで、実行
可能になる。

【００１７】〈実施例１〉図２に、本発明におけるソー
ス及びプロジェクト情報を内蔵した実行可能プログラム
のデータ構造、及び作成手順を示す。ここでプロジェク
ト情報とは、プログラムソースの名称、コンパイラオプ
ション、リンカオプション、生成する実行可能プログラ
ム名称などの一連のプログラム生成情報のことである。
ソース１００及びプロジェクト情報２００はコンパイラ
５０に入力される。コンパイラ５０は図１の従来方式と
同様に、ソース１００をコンパイルしてオブジェクトを
出力する。同時にソース１００及びプロジェクト情報２
００を、データサイズを小さくするため圧縮部６０で圧
縮して、圧縮形式のソース及びプロジェクト情報を出力
する。リンカ５８は前記のオブジェクト、圧縮形式のソ
ース及びプロジェクト情報を入力する。なお、図２で
は、圧縮部６０はコンパイラ５０と一体になっている
が、両者は分離していても構わない。リンカ５８は、図
１におけるリンカ５５の機能に加え、圧縮形式のソース
及びプロジェクト情報を入力して、ロードモジュールと
一体化させる機能を持つ。まず、リンカ５８は、入力し
たオブジェクトをリンクしてロード３５０を作成し、ま
たソースを１つにまとめて圧縮形式のソース１５０を作
成する。そして圧縮形式のプロジェクト情報も含めた三
者を一体化して、ロードモジュール３５０、圧縮形式の
ソース１５０及び圧縮形式のプロジェクト情報２５０か
ら成るソース内蔵型実行可能プログラム３２０を作成す
る。この際リンカ５８は、ソース内蔵型実行可能プログ
ラム３２０の冒頭部に、ヘッダラベル５００を作成す
る。このヘッダラベル５００には、例えば以下のような
情報が記録され、内蔵されたロード，ソース及びプロジ
ェクト情報を後に取り出すときに参照される。 ソース内蔵型実行可能プログラム３２０内での、ロ
ード３５０の開始アドレス及び長さ、 ソース１５０を構成するルーチン数（ソースが内臓
されていない場合は‘０’）、 ソース１５０を構成する全ルーチン分の、名称，開
始アドレス，及び長さ、 プロジェクト情報２５０の有無、 プロジェクト情報２５０が内蔵されている場合、そ
の開始アドレス及び長さ。

【００１８】図１における従来方式と異なる点は、リン
カが圧縮形式のソース及びプロジェクト情報を含む実行
可能プログラムを生成できる点、実行可能プログラムが
圧縮ソース及びプロジェクト情報を内蔵している点であ
る。なお、図２ではソース及びプロジェクト情報を実行
可能プログラムに内蔵させたが、ソースだけを内蔵した
実行可能プログラムを作成することも可能である。本実
施例によれば、ロードと、その作成に使用したソース，
プロジェクト情報を一体化して１つのプログラムにする
ため、これらのデータの一元管理が実現できる。

【００１９】次に、ソース内蔵型実行可能プログラムを
メモリ上にローディングする方法について、図３を用い
て説明する。既に述べたように、ソース内蔵型実行可能
プログラムは、ロード、ソース、プロジェクト情報の三
者を一体化することで、ロードとその作成リソース（ソ
ース及びプロジェクト情報）間の１対１の関係が明確に
なるという利点を持つ。しかし一体化した結果プログラ
ムサイズが大きくなり、これをそのままメモリ上にロー
ディングすると、メモリ使用量が増加してしまうという
課題も発生する。

【００２０】そこで本実施例におけるローダ７５は、ソ
ース内蔵型実行可能プログラムから必要なデータだけを
取り出してローディングする機能を有する。使用者は図
３のローダ７５に対し、ローディングしたいデータを指
定する。ユーザがローダ起動時にオプションとして、
「実行可能プログラム全体をローディングする」と指定
すればローダ７５は、実行可能プログラム３２０をその
ままローディングする。ユーザが、例えばロードの実行
のために「ロード３５０だけをローディングする」と指
定すればローダ７５は、ソース内蔵型実行可能プログラ
ム３２０の冒頭部にあるヘッダラベル５００に記録され
た前述の情報を参照し、ロード３５０の開始アドレス
及び長さといった情報を得る。そして実行可能プログラ
ム３２０からロード３５０だけを取り出してメモリ上に
ローディングする。また、ソースの参照や編集のために
「ソース１５０から指定したルーチンだけをローディン
グする」と指定すればローダ７５は、同様にヘッダラベ
ル５００に記録された前述の情報、を参照し、指定
したルーチンがソース１５０に内蔵されているか否か、
されていればその開始アドレス及び長さといった情報を
得、ソース１５０から指定したルーチンだけを取り出し
てメモリ上にローディングする。プロジェクト情報２５
０もソースと同様に、ヘッダラベル５００に記録された
情報、を参照することで、単独でローディングでき
る。本実施例によれば、ソース内蔵型実行可能プログラ
ムから必要なデータだけをメモリ上にローディングする
ことが可能になるので、ソース内蔵型実行可能プログラ
ム全体をローディングした場合よりメモリ使用量が少な
くて済む。

【００２１】〈実施例２〉図４は本発明における、ソー
ス、プロジェクト情報、及び設計／保守ドキュメント
（以下ドキュメント）を内蔵した実行可能プログラムの
データ構造、及びシステム構成図を示す。まず、図４に
おけるソース１００、プロジェクト情報２００、及びド
キュメント３００をコンパイラ５０に入力する。このコ
ンパイラは、データ圧縮部６０を有する点で従来の図１
と異なる。コンパイラ５０はソース１００をコンパイル
してオブジェクトを出力する。同時にソース１００、プ
ロジェクト情報２００、及びドキュメント３００を圧縮
部６０に入力して、圧縮されたソース、プロジェクト情
報、及びドキュメントを出力する。リンカ５８はオブジ
ェクトをリンクしてロード３５０を作成し、またソース
を１つにまとめて内蔵ソース１５０を作成する。そして
プロジェクト情報、及びドキュメントも含めたデータを
一体化して、ロードモジュール３５０、ソース１５０、
プロジェクト情報２５０、及びドキュメント３０９から
成るソース内蔵型実行可能プログラム３２０を作成す
る。

【００２２】本実施例によれば、ロードと、その作成に
使用したソース、プロジェクト情報、及びドキュメント
を一体化して１つのプログラムにするため、これらのデ
ータの一元管理が実現できる。なお、ソース等のデータ
を圧縮するのは、実行可能プログラム３５０を少しでも
小さくして、記録媒体の使用量を節約するためである。
また、図４ではソース、プロジェクト情報、及びドキュ
メントを実行可能プログラムに内蔵させたが、ソースだ
け、またはソースとプロジェクト情報だけを内蔵した実
行可能プログラムを作成することも可能である。さらに
図４では、圧縮部６０はコンパイラ５０と一体になって
いるが、両者は分離していても構わない。なお、ソース
内蔵型実行可能プログラム３２０はヘッダラベルを有し
ているが、図４においては図示を省略している。

【００２３】〈実施例３〉以下に第３の実施例につい
て、図５のシステム構成図を用いて述べる。図５のよう
に、本実施例におけるシステム構成は、ソース等取り出
し手段を有したデータ取り出し部３０、圧縮部６０を有
するコンパイラ５０、リンカ５８、データ解凍部６５、
及びこれらを処理手順に応じて連動させる制御部４０か
ら構成されている。データ解凍部６５は、圧縮部６０が
圧縮したデータを解凍する機能を持ち、圧縮部６０と対
で利用される。なお、図５においては、圧縮部６０はコ
ンパイラ５０に内蔵されているがコンパイラの外部にあ
ってもよく、また圧縮部６０とデータ解凍部６５が一体
になっていてもよい。さらには圧縮部６０とデータ解凍
部６５が一体になった装置がコンパイラ５０に内蔵され
ていてもよい。この実施例では、プロジェクト情報２０
０を参照してソース１００をコンパイル／リンクするこ
とで、ソース内蔵型実行可能プログラム３２０を生成す
る場合について述べる。ソース内蔵型実行可能プログラ
ムを生成する際は、プロジェクト情報２００を制御部４
０に対し指定すると、制御部４０がプロジェクト情報２
００を参照することにより、ソースを内蔵した実行可能
プログラムを生成するよう、コンパイラ５０、及びリン
カ５８を起動する。その結果コンパイラ５０がまずソー
ス１００をコンパイルしオブジェクト９０１を作成す
る。同時にコンパイラ５０の圧縮部６０が、ソース１０
０を入力データとして圧縮形式のソース９０２を出力す
る。リンカ５８は、前記のオブジェクト９０１と圧縮形
式ソース９０２を入力データとして、ロードモジュール
３５０と圧縮形式のソース１５０とを一体化した、ソー
ス内蔵型実行可能プログラム３２０を作成する。

【００２４】図１１は、本実施例のソース内蔵型実行可
能プログラムの作成過程における制御部４０の処理内容
を示す流れ図である。制御部４０は、ユーザから指定さ
れたプロジェクト情報から、ソース名、コンパイラオプ
ションの情報を取り出す（７００）。その後、コンパイ
ラオプションの情報に従ってコンパイラ５０を起動し、
ソースをコンパイルしてオブジェクトを作成する（７０
１）。次に、圧縮部６０を起動し、プロジェクト情報で
指定されたソースを圧縮した一時ファイルを作成する
（７０２）。その後、圧縮形式のソースの一時ファイル
をオブジェクトと一体化させるために、プロジェクト情
報からリンカオプションの情報を取り出す（７０３）。
こうして得たリンカオプションを使用し、リンカ５８を
起動する。リンカ５８は前述のオブジェクトと圧縮形式
のソースの一時ファイルを入力する。まずリンカ５８は
オブジェクトをリンクしてロードモジュールを作成し、
圧縮形式ソースの一時ファイルと一体化する。さらに、
ロードモジュールやソースを参照するための情報を記録
したヘッダラベル５００を作成し、ロードモジュール、
ソース、及びヘッダラベルからなるソース内蔵型実行可
能プログラムを作成する（７０４）。その後、制御部４
０は圧縮されたソースの一時ファイルを削除する（７０
５）。

【００２５】次に、前記ソース内蔵型実行可能プログラ
ムの生成装置により、ソース内蔵型実行可能プログラム
内に圧縮／格納されたソースを参照する場合について、
同じく図５を用いて述べる。まず、調査／修正する必要
のあるソース内蔵型実行可能プログラムを制御部４０に
指定する。制御部４０により起動されたデータ取り出し
部３０は、ソース内蔵型実行可能プログラム３２０内の
圧縮形式のソース１５０のコピーを作成し、取り出す。
次に、制御部４０はデータ解凍部６５を起動して、取り
出した圧縮形式のソース１５０を解凍することで、通常
形式のソース１００を得ることができる。この通常形式
のソース１００をエディタなどに表示することにより、
実行可能プログラム３２０中に内蔵されている圧縮形式
ソース１５０を参照する手段を提供することができる。

【００２６】図１２は、本実施例のソース内蔵型実行可
能プログラム内のソースを参照するまでの過程における
制御部４０の処理内容を示す流れ図である。まず、制御
部４０は、ユーザから指定されたソース内蔵型実行可能
プログラム内のヘッダラベル５００を参照し、圧縮形式
ソース１５０の、ソース内蔵型実行可能プログラム３２
０中での先頭位置を求める（８００）。その後、データ
取り出し部３０を起動し、ソースの先頭位置情報を参照
して、圧縮形式ソースの一時ファイルを得る（８０
１）。次に、データ解凍部６５を起動し、圧縮形式のソ
ースの解凍を行い、通常形式のソースを得る（８０
２）。最後に、制御部４０は、解凍部６５に入力した圧
縮形式ソースの一時ファイルを削除する（８０３）。

【００２７】以上の実施例３により、ソース内蔵型実行
可能プログラム内に、ロードモジュール生成に利用した
ソースを格納でき、ロードモジュールとソースの一元管
理が実現される。つまり、その実行可能プログラムを生
成する際に使用したソースをバージョンの誤りなく参照
することができ、誤ったソースを参照してデバッグする
ことを防ぐことができる。

【００２８】〈実施例４〉実施例３ではソースのみをソ
ース内蔵型実行可能プログラム内に格納していたが、プ
ロジェクト情報も内蔵したソース内蔵型実行可能プログ
ラムを生成できる。この実施例を図６を用いて説明す
る。まず、コンパイラ５０が、ソース１００及びプロジ
ェクト情報２００を入力する。コンパイラ５０はプロジ
ェクト情報２００に指定されたソース１００をコンパイ
ルしてオブジェクト９０１を出力し、同時にコンパイラ
５０の圧縮部６０がソース１００及びプロジェクト情報
２００を圧縮して、圧縮形式のソース９０２及びプロジ
ェクト情報９０３を出力する。リンカ５８は、前記のオ
ブジェクト９０１、圧縮形式のソース９０２、及び圧縮
形式のプロジェクト情報９０３を入力して、ロードモジ
ュール３５０、圧縮形式のソース１５０及び圧縮形式の
プロジェクト情報２５０とを一体化した、ソース内蔵型
実行可能プログラム３２０を作成する。ソース内蔵型実
行可能プログラム３２０に内蔵された圧縮形式のプロジ
ェクト情報２５０を参照する場合も、実施例３における
ソースと同様に、ソース内蔵型実行可能プログラム３２
０から圧縮形式のプロジェクト情報２５０を取り出し・
解凍し、プロジェクト情報２００を得ることができる。
これをエディタ等を用いて参照する。実施例４により、
ロードモジュール生成時に使用したソース及びプロジェ
クト情報を、実行可能プログラム内に格納でき、ロード
モジュール、ソース及びプロジェクト情報の一元管理が
実現される。つまり、その実行可能プログラムを生成す
る際に使用したソース及びプロジェクト情報をバージョ
ンの誤りなく参照することができ、誤ったソースまたは
プロジェクト情報を参照してデバッグすることを防ぐこ
とができる。

【００２９】図７は、本発明において図６に示したソー
ス内蔵型実行可能プログラムを作成するときの処理手順
を示すフローチャートである。実行可能プログラムを作
成する際は、まずプロジェクト情報をコンパイラに入力
する（５００）。そしてこのプロジェクト情報を参照し
て、コンパイルすべきソースをコンパイラに入力し（５
０５）、ソースをコンパイルする（５０８）。そして、
ユーザの要求に応じて、ソース内蔵型の実行可能プログ
ラムを作成するか否かを決定する（５１０）。作成しな
い場合は、コンパイラはオブジェクトだけを出力し（５
１５）、リンカはこのオブジェクトを入力して、ロード
モジュールだけから成る従来形式の実行可能プログラム
を作成する（５２０）。ソースを内蔵した実行可能プロ
グラムを作成する場合は、図７の５１０においてＹＥＳ
側に分岐し、コンパイラの圧縮部がソースを圧縮する
（５２５）。そして、ソースに加えてプロジェクト情報
も内蔵した実行可能プログラムを作成するか否かを、ユ
ーザの要求に応じて決定する（５３０）。作成しない場
合は、コンパイラはオブジェクト及び圧縮形式ソースを
出力し（５３５）、リンカはこのオブジェクト及び圧縮
形式ソースを入力データとして、圧縮形式のソースを内
蔵した実行可能プログラムを作成する（５４０）。ソー
ス及びプロジェクト情報を内蔵した実行可能プログラム
を作成する場合は、図７の５３０においてＹＥＳ側に分
岐し、コンパイラの圧縮部がプロジェクト情報を圧縮す
る（５４５）。そしてコンパイラはオブジェクト、圧縮
形式ソース及び圧縮形式プロジェクト情報を出力し（５
５０）、リンカはこのオブジェクト、圧縮形式ソース及
び圧縮形式プロジェクト情報を入力データとして、圧縮
形式のソースとプロジェクト情報を内蔵した実行可能プ
ログラムを作成する（５５５）。

【００３０】〈実施例５〉修正や機能拡張などでプログ
ラムを改造する場合の実施例について、図８を用いて説
明する。なお、図８以降では、ソース内蔵型実行可能プ
ログラムのヘッダラベルの図示と説明を省略する。ソー
ス内蔵型実行可能プログラム３２０を作成するのに使用
したソースデータ１５０は、一般的には主ルーチンとそ
の他のサブルーチン群など、多数のルーチンから成り立
っている。そして、例えば、サブルーチンの１つに対し
て修正作業を行なう際は、まず、このソース内蔵型実行
可能プログラム３２０を制御部４０に指定する。次に制
御部４０はデータ取り出し部３０、データ解凍部６５を
起動し、圧縮形式のソース１５０の取り出し・解凍を行
なうことによって通常形式のソース１００を得る。さら
に、制御部４０はプロジェクト情報についても、同様に
ソース内蔵型実行可能プログラム３２０から圧縮形式の
プロジェクト情報２５０を取り出し、解凍を行なうこと
によって通常形式のプロジェクト情報２００を得る。こ
のことにより、ソース内蔵型実行可能プログラム３２０
を生成した際の環境を再現できる。

【００３１】この得られた通常形式のソース１００中の
ルーチンの１つ１０１を、エディタ等を用いて修正作業
を行う。修正後のルーチンを１０２とする。次に、得た
プロジェクト情報２００を制御部４０に指定することに
より制御部４０は、ソース中のルーチンの１つ１０１を
修正して１０２としたことを、プロジェクト情報２００
に記録して更新する。更新後のプロジェクト情報を２０
１とする。プロジェクト情報２０１に従い、まずコンパ
イラ５０がソース１００のルーチンをすべてコンパイル
してオブジェクト９０１を作成する。同時にコンパイラ
５０の圧縮部６０がソース１００及びプロジェクト情報
２０１を圧縮し、圧縮形式のソース９０２及び圧縮形式
のプロジェクト情報９０３を出力する。リンカ５８は、
前記のオブジェクト９０１、圧縮形式のソース９０２、
及び圧縮形式のプロジェクト情報９０３を入力データと
して取り込む。まずリンカ５８は前記のオブジェクトを
リンクして、ソースの更新（ルーチン１０１→１０２）
を反映したロードモジュール３６０を作成する。次にリ
ンカ５８は、前記のロードモジュール３６０、圧縮形式
のソース、及び圧縮形式のプロジェクト情報を一体化し
て、ソースの修正を反映したソース内蔵型実行可能プロ
グラム３３０を生成する。このソース内蔵型実行可能プ
ログラム３３０は、ロードモジュール３６０、ソース１
６０、及びプロジェクト２６１から成る。この際、図８
におけるルーチン１０１（修正後は１０２）を除いて
は、ソース内蔵型実行可能プログラム３２０中の圧縮形
式のソース１５０を解凍して得た通常形式のソース１０
０を変更せず使用することにより、ルーチン１０１以外
のソースデータは、ソース内蔵型実行可能プログラム３
２０を生成した際に使用したバージョンを再度使用して
再生成したことが保証される。この作業を繰り返すこと
により、過去の環境を確実に継承し、さらにその環境の
一部に修正を加えて、修正／保守作業を行なうことがで
きる。

【００３２】〈実施例６〉次に、この発明における実行
可能プログラムに異常が発生した時のデバッグ情報取得
について図９を用いて説明する。図９は、実行可能プロ
グラムの異常発生時に、デバッグ情報を自動的に取得す
るために必要なシステムの構成図である。ソース内蔵型
実行可能プログラム３２０の実行時に異常が発生した際
に、ＯＳもしくはコンパイラ実行時ライブラリがこの異
常を検知し、実行可能プログラムの再生成・再実行を司
る制御部４０に異常が発生したことを通知する。制御部
４０は実行可能プログラム３２０からプロジェクト情報
２５０を取り出し解凍して、プロジェクト情報２００を
得る。さらに制御部４０は、プロジェクト情報２００を
参照して、実行可能プログラム３２０作成時に指定した
オプションの内容を調べる。それによって実行可能プロ
グラム３２０が、デバッグ情報の出力が可能なプログラ
ムかを判断する。デバッグ情報には例えば、エラーの発
生した箇所のモジュール名や行番号を出力するトレース
バック情報、引数の型・数等の対応がモジュール間で正
しく取れているかを出力する引数情報などがある。しか
し、前述の従来の技術で説明したように、通常デバッグ
終了後のロードモジュールは、実行性能向上及びプログ
ラムサイズの節約のために、デバッグ情報出力オプショ
ンを指定せずに作成している。その場合は、デバッグ情
報出力オプションを指定したロードモジュールを復活さ
せる必要がある。

【００３３】制御部４０は、プロジェクト情報２００に
デバッグ情報出力指定オプションを追加した新しいプロ
ジェクト情報２１０を作成し、さらに実行可能プログラ
ム３２０からソース１５０をすべて取り出し・解凍し
て、ソース１００を得る。次に更新されたプロジェクト
情報２１０を参照し、コンパイラ５０がソースデータ１
００をすべてコンパイルしてオブジェクト９０１を作成
する。同時にコンパイラ５０の圧縮部６０がソース１０
０及びプロジェクト情報２１０を圧縮して、圧縮形式ソ
ース９０２と圧縮形式プロジェクト情報９０３を出力す
る。リンカ５８は前記のオブジェクト９０１、圧縮形式
ソース９０２及び圧縮形式プロジェクト情報９０３を入
力データとして取り込み、ソース内蔵型実行可能プログ
ラム３３５を生成する。ソース内蔵型実行可能プログラ
ム３３５は、ロードモジュール３７０、ソース１７０、
及びプロジェクト情報２７０から成る。ロードモジュー
ル３７０は、デバッグ情報出力オプションを使用して作
成したため、デバッグ情報の出力が可能である。その
後、制御部４０は、必要に応じて入出力データを割り当
て、異常発生時の入力データを再び使用して、再生成し
たデバッグ情報取得可能なソース内蔵型実行可能プログ
ラム３３５を実行し、デバッグ情報を出力先データに出
力する。このことにより、デバッグ情報を取得すること
ができる。以上により、デバッグ情報取得が不可能な実
行可能プログラムに異常が発生した際も、デバッグ情報
の取得が可能な実行可能プログラムを再生成／再実行
し、デバッグ情報を取得するまでの過程を自動化できる
ので、環境の変化によるデバッグ情報の取得の失敗を防
ぐことができる。

【００３４】図１０は、本発明において、実行可能プロ
グラムの実行中に異常が発生したときの処理手順を示す
フローチャートである。ソース内蔵型実行可能プログラ
ムの実行中に異常が発生したとき（６００）、システム
制御部が実行可能プログラムに内蔵されたプロジェクト
情報を取り出し・参照して（６０５）、デバッグ情報の
出力が可能な実行可能プログラムかを判断する（６１
０）。可能なら、デバッグ情報を取得する（６１５）。
デバッグ情報出力が不可能な実行可能プログラムなら、
取り出したプロジェクト情報にデバッグ情報出力オプシ
ョンを追加し（６２０）、さらに実行可能プログラムに
内蔵されたソースを取り出す（６２５）。６２０で修正
したプロジェクト情報を参照して、６２５で取り出した
ソースを再コンパイル・リンクし、デバッグ情報の出力
が可能なロードを作成する（６３０）。このロードと６
２５で取り出したソースと６２０で修正したプロジェク
ト情報を一体化して、新しいソース内蔵型実行可能プロ
グラムを作成する（６３５）。この実行可能プログラム
の実行に入力データが必要なら（６４０）入力データを
割り当てた後（６４５）、実行可能プログラムを再実行
する（６５０）。その結果デバッグ情報を取得できる
（６５５）。

【００３５】〈実施例７〉ソース、プロジェクト情報、
ドキュメントといったデータを、暗号化して内蔵すると
きの実施例を、図１３を用いて説明する。前述のソース
内蔵型実行可能プログラムを、開発時に使用するだけで
なく、その形態のままユーザに提供したいことがある。
例えば、プログラムを各ユーザの要望に応じて仕様を変
更（カスタマイズ）している場合である。その場合、各
ユーザに提供したプログラムごとにソースが異なるた
め、すべてのソースを開発者側で保管していると、例え
ばユーザから問い合わせがあった場合、間違えて別のソ
ースを調査してしまう危険性がある。それを防止するた
めには、ロードを実施例１のソース内蔵型プログラムの
形態でソース等と一体化してユーザに提供すれば、ロー
ドとソースとの対応関係が明らかになり、ロードに対応
したソースを確実に調査できる。しかし一方で、ユーザ
に対してソースが隠蔽できなくなるため、ソースを流用
される可能性が生じる。そのためロード以外のデータは
暗号化することによって、機密保持を図っていることが
特徴である。

【００３６】まず、図１３におけるソース１００、プロ
ジェクト情報２００、及びドキュメント３００をコンパ
イラ５０に入力する。このコンパイラは、データ圧縮／
暗号化部６１を有する点で実施例１（図２）、実施例２
（図４）と異なる。コンパイラ５０はソース１００をコ
ンパイルしてオブジェクトを出力する。同時にソース１
００、プロジェクト情報２００、及びドキュメント３０
０を圧縮／暗号化部６１に入力して、圧縮／暗号化され
たソース、プロジェクト情報、及びドキュメントを出力
する。リンカ５８は実施例１、２と同様にロード３５０
を作成し、圧縮／暗号化形式のソース１５１、同プロジ
ェクト情報２５１、及び同ドキュメント３１１とを一体
化して、内蔵データを圧縮／暗号化したソース内蔵型実
行可能プログラム３２０を作成する。本実施例によれ
ば、ロードとソースの対応を明確にするために、ソース
内蔵型実行可能プログラムをユーザへ提供しても、ユー
ザに対するソース等のデータの機密保護が実現できる。

【００３７】なお、図１３ではソース、プロジェクト情
報、及びドキュメントを実行可能プログラムに内蔵させ
たが、ソースだけ、またはソースとプロジェクト情報だ
けを内蔵した実行可能プログラムを作成することも可能
である。また、図１３では、圧縮／暗号化部６１はコン
パイラ５０と一体になっているが、両者は分離していて
も構わない。また、前述の、カスタマイズを行ったソー
スの場合、ソースすべてを実行可能プログラムに内蔵す
るのではなく、標準ソースとの差分情報のみを内蔵する
方法もある。こうすれば、標準ソースは開発者が保管し
ておき、ユーザが保有する一体型実行可能プログラム内
の差分情報と、この標準ソースを合わせることで、カス
タマイズされたソース全体を得ることが可能である。か
つ内蔵するデータを、ソース全体ではなく差分情報だけ
にすることで、実行可能プログラムのサイズが縮小で
き、ローディング時のメモリ使用量を節約できる。

【００３８】〈実施例８〉図１４は本発明における、デ
バッグ用ソースを内蔵したソース内蔵型実行可能プログ
ラムのデータ構造、及びシステム構成図を示す。まず、
実施例７と同様、ソース１００、プロジェクト情報２０
０、ドキュメント３００から、オブジェクトと圧縮／暗
号形式のソース、プロジェクト情報、及びドキュメント
を出力する。さらにデバッグ用ソース１３０を圧縮／暗
号化部６１に入力して、圧縮／暗号化されたデバッグ用
ソースを出力する。リンカ５８は前記のオブジェクト、
圧縮／暗号形式ソース、同プロジェクト情報、同ドキュ
メント、及び同デバッグ用ソースを入力する。まずリン
カは実施例２と同様にオブジェクトをリンクしてロード
３５０を作成する。このロードと、前記の圧縮／暗号形
式ソース１５１、同プロジェクト情報２５１、同ドキュ
メント３１１、及び同デバッグ用ソース１８１を一体化
して、デバッグ用ソースも内蔵した、デバッグ用ソース
内蔵型実行可能プログラム３４０を作成する。この実行
可能プログラムはローダ７５を介して実行される。な
お、本実施例におけるリンカ５８、ローダ７５は、実施
例７（図１３）のリンカ５８、ローダ７５と、それぞれ
同じものである。本実施例によれば、一度作成したデバ
ッグ用ソースをロードと一体化して保存しておくこと
で、後日の再利用がしやすくなる。

【００３９】図１５は、実施例７〜８におけるソース内
蔵型実行可能プログラムの作成手順を示すフローチャー
トである。まずソースをコンパイルしてオブジェクトを
作成する（１６００）。ソースを実行可能プログラムに
内蔵するなら（１６０５）、ソースを圧縮／暗号化する
（１６１０）。さらにプロジェクト情報を内蔵するなら
（１６１５）、プロジェクト情報を圧縮／暗号化する
（１６２０）。さらにドキュメントを内蔵するなら（１
６２５）、ドキュメントを圧縮／暗号化する（１６３
０）。さらにデバッグ用ソースを内蔵するなら（１６３
５）、デバッグ用ソースを圧縮／暗号化する（１６４
０）。そしてロードと他のデータ（ソース、プロジェク
ト情報、ドキュメント、及びデバッグ用ソース）を一体
化して、ソース内蔵型実行可能プログラムを作成する
（１６４５）。

【００４０】〈実施例９〉本発明のソース内蔵型実行可
能プログラムに対し、ソースを参照したり、修正や機能
追加などのためにで改造したりする場合の実施例につい
て、図１６を用いて説明する。ソース内蔵型実行可能プ
ログラム３３１は、ロード３５０、 暗号化形式のソー
ス１５１、同プロジェクト情報２５１から成る（実施例
７〜８で使用したドキュメントやデバッグ用ソースは、
本実施例では使用しないので省略する）。実行可能プロ
グラム３３１を作成するのに使用したソース１５１は、
一般的には主プログラムとその他の副プログラム群な
ど、多数のプログラムから成り立っている。そして、例
えば副プログラムの１つに対して参照または修正を行な
う際は、まずこのソース内蔵型実行可能プログラム３３
１を制御部４０に指定する。次に制御部４０はデータ取
り出し部３０、データ解凍／復号化部６５を起動し、圧
縮／暗号形式のソース１５１を取り出し、解凍／復号化
を行なうことによって、通常形式のソース１００を得
る。ソースを参照するだけなら、このソース１００から
参照したいルーチンを選択してエディタ等を用いて参照
する。ソースを修正し、ロードに反映させる場合は、プ
ロジェクト情報も同様に、圧縮／暗号形式のプロジェク
ト情報２５１を取り出し、解凍／復号化して、通常形式
のプロジェクト情報２００を得る。このことにより、ソ
ース内蔵型実行可能プログラム３３１を生成した際の環
境を再現できる。

【００４１】ソース修正者は、先に取り出したソース１
００中のプログラムの１つ１１０を、エディタ等を用い
て修正を行う。修正後のプログラムを１１１とする。次
に、プロジェクト情報２００を制御部４０に指定するこ
とにより、プロジェクト情報２００に従い、まずコンパ
イラ５０がソース１００のプログラムをすべてコンパイ
ルしてオブジェクトを作成する。さらにコンパイラの圧
縮／暗号化部６１が、修正を反映したソース１００、及
びプロジェクト情報２００を入力して圧縮／暗号化す
る。リンカ５８は前述のオブジェクト、圧縮／暗号形式
のソース、及び同プロジェクト情報を入力データとして
取り込む。まず、リンカは、プロジェクト情報２００を
参照してオブジェクトをリンクし、ソースの修正を反映
したロード３５２を作成する。次に、リンカ５８は、前
述のロード３５２、修正後に圧縮／暗号化されたソース
１５２、及びプロジェクト情報２５２を一体化して、ソ
ースの修正を反映したソース内蔵型実行可能プログラム
３３２を作成する。本実施例によれば、ソースの修正が
確実にロードに反映され、ソースとロードの更新状況が
一致しないことによる混乱がなくなる。なお本実施例で
は、ロードと一体化したデータはソースとプロジェクト
情報だけであるが、ドキュメントやデバッグ用ソースを
も内蔵したプログラムでも同様にソース、ロードの修正
が実施できる。

【００４２】〈実施例１０〉本発明の実行可能プログラ
ムに内蔵した設計／保守ドキュメント（以下ドキュメン
ト）を、プログラム保守等の目的で参照する場合の実施
例について、図１７を用いて説明する。実施例７でも述
べたように、ユーザに提供するプログラムは、ユーザご
との実行環境や要望に応じて仕様を変更する、いわゆる
カスタマイズを行う。従って開発者としては、どのユー
ザにどのようなカスタマイズを行ったのかという情報
が、プログラム調査や保守の時に必要になってくる。し
かし、そのような情報をすべて開発者側で管理している
と、間違えて他のユーザに提供したプログラムの情報を
参照してしまう可能性がある。そのため、カスタマイズ
時に生じた標準仕様との差異などの情報を、電子化した
ドキュメントにまとめて、これまでの実施例におけるソ
ースやプロジェクト情報と同様に実行可能プログラムに
内蔵し、必要なときにはそれを参照する。この方法だ
と、他のユーザに提供したプログラムの情報を参照して
しまうことはなくなる。ソース内蔵型実行可能プログラ
ム３２０は、ロード３５０、 圧縮／暗号化形式のソー
ス１５１、同プロジェクト情報２５１、及び同ドキュメ
ント３１１から成る（実施例８で使用したデバッグ用ソ
ースは、本実施例では使用しないので省略する）。プロ
グラムの調査や保守のために、ドキュメント３１１を参
照したいときは、実施例９と同様にまずソース内蔵型実
行可能プログラム３２０を制御部４０に指定する。次に
制御部４０はデータ取り出し部３０、データ解凍／復号
化部６６を起動し、圧縮／暗号形式のドキュメント３１
１を取り出し、解凍／復号化を行うことによって、通常
形式のドキュメント３００を得る。このドキュメント３
００を、エディタ等を用いて参照する。

【００４３】図１８は、本実施例における実行可能プロ
グラムのソース参照／修正、及びドキュメント参照の処
理手順を示すフローチャートである。まずソース、ドキ
ュメントのどちらを参照するかを選択する（１６５
０）。ソースを参照する場合は、実行可能プログラムに
内蔵されたソースを取り出す（１６５５）。ソースを参
照するだけなら（１６６０）、取り出したソースをエデ
ィタで開いて参照する（１６６５）。ソース（及びロー
ド）の修正も行うなら、後の再コンパイル等のためにプ
ロジェクト情報も取り出す（１６７０）。そしてエディ
タを用いてソースを修正し（１６７５）、この修正ソー
スと先に取り出したプロジェクト情報を用いて、修正版
ロードを作成する（１６８０）。そしてこの修正版ロー
ドと、修正版ソース、同プロジェクト情報を一体化し
て、修正版・ソース内蔵型実行可能プログラムを作成す
る（１６８５）。また、ドキュメントを参照する場合
は、実行可能プログラムに内蔵されたドキュメントを取
り出す（１６９０）。そして、取り出したドキュメント
をエディタを用いて参照する（１６９５）。

【００４４】〈実施例１１〉本実施例では、本発明にお
けるデバッグ用ソースを内蔵したソース内蔵型実行可能
プログラムを使用して、ロード実行中に異常が発生した
ときに、デバッグ用ロードを自動的に作成・実行する方
法を、図１９を用いて示す。デバッグ用ソースを内蔵し
たデバッグ用ソース内蔵型実行可能プログラム３４０の
実行中に異常が発生すると、制御部４０はデータ取り出
し部３０及びデータ解凍／復号化部６６を起動して、実
行可能プログラム３４０に内蔵されたデバッグ用ソース
１８１を取り出し、通常形態のデータに戻す。コンパイ
ラ５０はこのデバッグ用ソースを入力データとして受け
取り、コンパイルを行ってオブジェクトを作成する。リ
ンカ５５は、前述のオブジェクトと、実行可能プログラ
ム３４０のロード３５０とを入力データとして受け取
り、またプロジェクト情報２５１も参照して、これらの
オブジェクトとロード３５０をリンクして、デバッグ用
ロード３９０を作成する。このロード３９０は、直ちに
ローダ７０によってメモリ上にローディングされ、実行
される。そしてこの実行結果を参照することで、デバッ
グ情報を得られる。デバッグ用ロード３９０は、他のデ
ータを内蔵しない従来形式のロードであるため、従来の
ローダ７０が使用できる。本実施例によれば、デバッグ
時に行う「デバッグ用ロードの作成・実行」という手順
が自動的に行われるので、デバッグ時間が短縮できる。
なお本実施例の実行可能プログラムはドキュメントを内
蔵していないが、ドキュメントを内蔵したプログラムで
も同様にデバッグ用ロードの作成・実行が可能である。

【００４５】〈実施例１２〉本実施例では、本発明にお
けるデバッグ用ソース内蔵型実行可能プログラムをメモ
リ上にローディングする際に、ロード本体以外のデータ
はそのアドレスだけをローディングする方法を、図２０
を用いて示す。本発明におけるデバッグ用ソース内蔵型
実行可能プログラムは、ロード以外のデータと一体化し
ているため、従来の単体ロードに比べそのプログラムサ
イズが大きくなる。そこで本実施例ではローディング時
のメモリ節約のために、ソース等のロード以外のデータ
は、データそのものではなくそのアドレス情報だけをロ
ーディングする。図２０のデバッグ用ソース内蔵型実行
可能プログラム３４０（以下、実行可能プログラム３４
０と呼ぶ）は、記録媒体上では実施例１１（図１９）に
おけるデバッグ用ソース内蔵型実行可能プログラム３４
０と同じものである。ローダ７６は、実行可能プログラ
ム３４０に対し、ロード本体（３５０）はメモリ上にロ
ーディングし、ロード以外のデータについては、データ
そのものに替わってそのアドレス情報のみを取り出して
ローディングする機能を有する点で、図１のローダ７０
や図３以降のローダ７５と異なる。まず、ローダ７６
は、実行可能プログラム３４０からロード３５０を取り
出す。さらにソース１５１、プロジェクト情報２５１、
及びデバッグ用ソース１８１の、記録媒体上での開始ア
ドレスを入力データとして得る。そしてロード３５０の
末尾に領域を追加して、他のデータの開始アドレス３８
５を格納し、こうして作成したアドレス内蔵ロード３８
０をメモリ上にローディングすることで実行できる。こ
の結果メモリ所要量は、通常のロードに比べて高々数十
バイトの増加で済み、メモリの節約が実現できる。な
お、図２０ではソース、プロジェクト情報、及びデバッ
グ用ソースを実行可能プログラムに内蔵させたが、ソー
スだけ、またはソースとプロジェクト情報だけを内蔵し
た実行可能プログラムを作成することも可能である。ま
た、さらにドキュメントを内蔵させるようにしてもよ
い。

【００４６】次に、このアドレス内蔵ロード３８０の実
行中に異常が発生した際に、実施例１１と同様にデバッ
グ用ロードを自動的に作成・実行する方法について述べ
る。アドレス内蔵ロード３８０の実行中に異常が発生す
ると、制御部４０はアドレス情報３８５を参照し、プロ
ジェクト情報２５１、デバッグ用ソース１８１の記録媒
体上でのアドレスを得る。データ取り出し部３０はこの
アドレスを元にデバッグ用ソース１８１を取り出し、デ
ータ解凍／復号化部６６に入力する。データ解凍／復号
化部６６は、入力された暗号データを解凍／復号化して
通常形式のデータに戻す。以後は実施例１１と同様に、
プロジェクト情報２５１を参照してデバッグ用ソース１
８１をコンパイル／リンクし、デバッグ用ロードを作成
して実行する。

【００４７】図２１は本実施例における、デバッグ用ソ
ースを内蔵した実行可能プログラムを用いて、異常発生
時にデバッグ用ロードを自動作成・実行する場合の処理
手順を示すフローチャートである。まず、実行可能プロ
グラムの実行中に異常が発生すると（１７００）、実行
可能プログラム内にデバッグ用ソースが内蔵されていれ
ば（１７０５）、デバッグ用ソースを取り出す（１７１
０）。デバッグ用ソースそのものではなくアドレスが内
蔵されていれば（１７１５）、そのアドレスを参照して
記録媒体上のデバッグ用ソースを取り出す（１７２
０）。そしてそのデバッグ用ソースをコンパイルしてオ
ブジェクトを作成する（１７２５）。そしてこのオブジ
ェクトと元のロードをリンクしてデバッグ用ロードを作
成する（１７３０）。そしてこのデバッグ用ロードを直
ちに実行し（１７３５）、デバッグ情報を取得する（１
７４０）。

【００４８】

【発明の効果】本発明によれば、従来個別に管理してい
たロードモジュールと、その作成に必要なソースデー
タ、プロジェクト情報（コンパイルオプション、使用ソ
ース名、作成ロード名等）、及び設計／保守ドキュメン
トとを一体化した実行可能プログラムを作成すること
で、これらのデータの一元管理が実現でき、人為的なミ
スによる過去に生成した実行可能プログラムの開発環境
の再現の失敗を防ぐことができ、ロード作成時の作業環
境が確実に再現できる。また、異常が発生した実行可能
プログラムがデバッグ情報を取得できない場合でも、自
動的にデバッグ情報を取得できる実行可能プログラムを
再生成／再実行して、異常発生からデバッグ情報取得ま
での過程の自動化／時間の短縮化を実現し、実行環境の
変化によるデバッグ情報取得の失敗を防ぐことができ
る。また、実行可能プログラムに内蔵されたソース等の
データを暗号化することにより、ソース内蔵型実行可能
プログラムをユーザに提供しても、ソースに関する機密
保護が実現できる。さらに、実行可能プログラム内にあ
らかじめデバッグ用ソースを内蔵しておき、実行中に異
常が発生した際はこのデバッグ用ソースを用いて自動的
にデバッグ用ロードを作成・実行することにより、デバ
ッグ作業が短時間かつ間違いなく行うことができる。

【図面の簡単な説明】

【図１】従来形式の実行可能プログラムのデータ構造
と、その作成手順を示す図である。

【図２】本発明による、ロード、ソース、プロジェクト
情報を一体化した実行可能プログラムのデータ構造と、
その作成手順を示す図である。

【図３】本発明のローダによる、ソース内蔵型実行可能
プログラムのメモリ上へのローディングする方法を説明
するための図である。

【図４】ロード、ソース、プロジェクト情報、及び設計
／保守ドキュメント（以下ドキュメント）を内蔵した実
行可能プログラムのデータ構造と、その作成手順を示す
図である。

【図５】ソース内蔵型実行可能プログラムに、ソースを
圧縮・格納し、また取り出し・解凍する際の処理の流れ
を示す図である。

【図６】ソース内蔵型実行可能プログラムに、プロジェ
クト情報を圧縮・格納し、また取り出し・解凍する際の
処理の流れを示す図である。

【図７】ソース内蔵型実行可能プログラムの作成手順の
フローチャートを示す図である。

【図８】ソース内蔵型実行可能プログラムに対し修正処
理を行う際の処理の流れを示す図である。

【図９】ソース内蔵型実行可能プログラムの実行中に異
常が発生したときの処理の流れを示す図である。

【図１０】ソース内蔵型実行可能プログラムの実行中に
異常が発生したときの処理手順のフローチャートを示す
図である。

【図１１】ソース内蔵型実行可能プログラムを作成する
際の制御部の処理内容のフローチャートを示す図であ
る。

【図１２】ソース内蔵型実行可能プログラムから内蔵さ
れたソースを取り出して参照する際の制御部の処理内容
のフローチャートを示す図である。

【図１３】ソース等の内蔵データを暗号化したソース内
蔵型実行可能プログラムのデータ構造と、その作成手順
を示す図である。

【図１４】ロード、ソース、プロジェクト情報、ドキュ
メント、及びデバッグ用ソースを内蔵した実行可能プロ
グラムのデータ構造と、その作成手順を示す図である。

【図１５】ソース内蔵型実行可能プログラムを作成する
手順のフローチャートを示す図である。

【図１６】ソース内蔵型実行可能プログラムのソースを
参照する、あるいはソース（及びロード）を修正する際
の処理の流れを示す図である。

【図１７】ドキュメントを内蔵した実行可能プログラム
から、ドキュメントを取り出して参照する際の処理の流
れを示す図である。

【図１８】ソース内蔵型実行可能プログラムのソースま
たはドキュメントを参照する、あるいはソース（及びロ
ード）を修正する際の処理のフローチャートを示す図で
ある。

【図１９】デバッグ用ソースを内蔵した実行可能プログ
ラムの異常発生時に、デバッグ用ロードを自動的に作成
・実行する際の処理の流れを示す図である。

【図２０】実行可能プログラムの、ロードを除くデータ
はそのアドレスだけをロード本体と共にローディング
し、かつ異常発生時にデバッグ用ロードを自動的に作成
・実行する際の処理の流れを示す図である。

【図２１】デバッグ用ソースを内蔵した実行可能プログ
ラムの異常発生時に、デバッグ用ロードを自動的に作成
・実行する際の処理のフローチャートを示す図である。

【符号の説明】

３０ データ取り出し部 ４０ 制御部 ５０ コンパイラ ５５ リンカ（従来型） ５８ リンカ ６０ 圧縮部 ６１ 圧縮／暗号化部 ６５ データ解凍部 ６６ データ解凍／復号化部 ７０ ローダ（従来型） ７５、７６ ローダ １３０ デバッグ用ソース １５０、１５１ 圧縮形式のソース １８１ デバッグ用ソース ２５０、２５１、２５２ 圧縮形式のプロジェクト情報 ３００、３１１ ドキュメント ３２０、３３０、３３１、３３２、３３５ ソース内蔵
型実行可能プログラム ３４０ デバッグ用ソース内蔵型実行可能プログラム ３５０、３５２、３６０、３７０、３８０ ロード ３９０ デバッグ用ロード ５００ ヘッダラベル ９０１ コンパイラが出力したオブジェクト ９０２ コンパイラの圧縮部が出力した圧縮形式のソー
ス ９０３ コンパイラの圧縮部が出力した圧縮形式のプロ
ジェクト情報

───────────────────────────────────────────────────── フロントページの続き (72)発明者 佐藤 収 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア事業部内 (72)発明者 武田 浩一 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア事業部内 (72)発明者 中嶋 啓人 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア事業部内 (72)発明者 吉川 聡 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア事業部内 Ｆターム(参考） 5B076 AB02 BA05 5B081 BB08 CC51

Claims (7)

【特許請求の範囲】
1. 【請求項１】 ソースデータをコンパイラによりコンパ
   イルしてオブジェクトモジュールを生成し、 ソースデータを圧縮部で圧縮し圧縮形式のソースデータ
   を生成し、 前記オブジェクトモジュールをリンカによりリンクして
   ロードモジュールを生成すると共に該リンカにより該ロ
   ードモジュールと前記圧縮形式のソースデータを一体化
   してソース内蔵型実行可能プログラムを生成することを
   特徴とするソース内蔵型実行可能プログラム生成方法。
2. 【請求項２】 請求項１記載のソース内蔵型実行可能プ
   ログラム生成方法において、 プロジェクト情報を圧縮部で圧縮し圧縮形式のプロジェ
   クト情報を生成し、 前記リンカにより前記ロードモジュールと前記圧縮形式
   のソースデータと該圧縮形式のプロジェクト情報を一体
   化してソース内蔵型実行可能プログラムを生成すること
   を特徴とするソース内蔵型実行可能プログラム生成方
   法。
3. 【請求項３】 請求項１または請求項２記載のソース内
   蔵型実行可能プログラム生成方法において、 設計／保守ドキュメントを圧縮部で圧縮し圧縮形式の設
   計／保守ドキュメントを生成し、 前記リンカにより前記ロードモジュールと該圧縮形式の
   設計／保守ドキュメントと前記他の圧縮形式のデータを
   一体化してソース内蔵型実行可能プログラムを生成する
   ことを特徴とするソース内蔵型実行可能プログラム生成
   方法。
4. 【請求項４】 請求項１または請求項２または請求項３
   記載のソース内蔵型実行可能プログラム生成方法におい
   て、 デバッグ用ソースを圧縮部で圧縮し圧縮形式のデバッグ
   用ソースを生成し、 前記リンカにより前記ロードモジュールと該圧縮形式の
   デバッグ用ソースと前記他の圧縮形式のデータを一体化
   してソース内蔵型実行可能プログラムを生成することを
   特徴とするソース内蔵型実行可能プログラム生成方法。
5. 【請求項５】 請求項１乃至請求項４のいずれかの請求
   項記載のソース内蔵型実行可能プログラム生成方法にお
   いて、 前記圧縮部で圧縮した全ての圧縮形式のデータを暗号化
   部で暗号化し、圧縮／暗号化形式のデータを生成し、 前記リンカにより前記ロードモジュールと該圧縮／暗号
   化形式のデータを一体化してソース内蔵型実行可能プロ
   グラムを生成することを特徴とするソース内蔵型実行可
   能プログラム生成方法。
6. 【請求項６】 請求項１乃至請求項５のいずれかの請求
   項記載のソース内蔵型実行可能プログラム生成方法によ
   り生成されたソース内蔵型実行可能プログラムのメモリ
   上へのローディング方法であって、 記録媒体上に記録された前記ロードモジュールはメモリ
   上にローディングし、該ロードモジュール以外の各デー
   タについては、データそのものに替わってデータの記録
   された記録媒体上におけるデータのアドレス情報だけを
   取り出してローディングすることを特徴とするローディ
   ング方法。
7. 【請求項７】 ソースデータをコンパイラでコンパイル
   し、オブジェクトモジュールを取得しメモリ格納するス
   テップと、 ソースデータおよびプロジェクト情報を圧縮部で圧縮
   し、圧縮形式のソースデータおよび圧縮形式のプロジェ
   クト情報を取得しメモリ格納するステップと、 前記取得したオブジェクトモジュールをリンカでリンク
   しロードモジュールを生成するステップと、 前記リンカで該生成したロードモジュールと前記取得し
   た圧縮形式のソースデータおよび圧縮形式のプロジェク
   ト情報を一体化し、ソース内蔵型実行可能プログラムを
   生成するステップを有するソース内蔵型実行可能プログ
   ラム生成プログラムを記録したコンピュータ読み取り可
   能な記録媒体。