JP2012018641A - ソフトウェア開発システム - Google Patents

Abstract

【課題】ソフトウェアに含まれるエンディアン依存箇所を検出すること。
【解決手段】実行プログラムを模擬実行するＣＰＵモデルおよび前記ＣＰＵモデルのワークエリアとしてのメモリモデルを備える命令セットシミュレータと、前記実行プログラムが含む前記メモリモデルに対するアクセス命令の実行を監視し、同一箇所に対する書き込み時のデータ長と読み出し時のデータ長との相異を検出したとき、検出時の実行箇所をエンディアン依存箇所として通知するチェッカと、を備える。
【選択図】図３

Description

本発明の実施形態は、ソフトウェア開発システムに関する。

従来、あるプロセッサ向けに開発されたソフトウェアを、そのプロセッサとは異なるエンディアン方式の別のプロセッサに移植する場合、ソフトウェアにエンディアン依存コードが含まれているとき、該エンディアン依存コードを修正する必要が生じる。

特開平５−１１９９６０号公報

本発明は、ソフトウェアに含まれるエンディアン依存箇所を検出するソフトウェア開発システムを提供することを目的とする。

本願発明の一態様によれば、実行プログラムを模擬実行するＣＰＵモデルおよび前記ＣＰＵモデルのワークエリアとしてのメモリモデルを備える命令セットシミュレータと、前記実行プログラムが含む前記メモリモデルに対するアクセス命令の実行を監視し、同一箇所に対する書き込み時のデータ長と読み出し時のデータ長との相異を検出したとき、検出時の実行箇所をエンディアン依存箇所として通知するチェッカと、を備えることを特徴とするソフトウェア開発システムが提供される。

図１は、第１の実施の形態のソフトウェア開発システムのハードウェア構成例を示すブロック図である。 図２は、開発対象プログラムの例を説明する図である。 図３は、第１の実施の形態のソフトウェア開発システムの機能構成を説明するブロック図である。 図４は、アクセス履歴テーブルのデータ構造例を説明する図である。 図５は、第１の実施の形態のソフトウェア開発システムの動作を説明するフローチャートである。 図６は、第２の実施の形態のソフトウェア開発システムの機能構成を説明する図である。 図７は、第２の実施の形態のソフトウェア開発システムの動作を説明するフローチャートである。 図８は、ハードウェア・リソースの動作を模擬するモデルが追加されたソフトウェア開発システムの機能構成を説明する図である。 図９は、開発対象プログラムの例を説明する図である。 図１０は、第３の実施の形態のソフトウェア開発システムの機能構成を説明する図である。

以下に添付図面を参照して、本発明の実施の形態にかかるソフトウェア開発システムを詳細に説明する。なお、これらの実施の形態により本発明が限定されるものではない。

（第１の実施の形態）
図１は、本発明の第１の実施の形態にかかるソフトウェア開発システムのハードウェア構成例を示すブロック図である。

図示するように、ソフトウェア開発システム１００は、ＣＰＵ（Central Processing Unit）１、ＲＡＭ（Random Access Memory）２、ＲＯＭ（Read Only Memory）３、入力装置４および表示装置５を備えるコンピュータ構成となっている。ＣＰＵ１、ＲＡＭ２、ＲＯＭ３、入力装置４および表示装置５は、バスラインを介して夫々接続されている。

表示装置５は、液晶モニタなどの表示装置であり、ＣＰＵ１からの指示に基づいて、操作画面などのユーザに対する出力情報を表示する。入力装置４は、マウスやキーボードを備えて構成され、ユーザからのソフトウェア開発システム１００の操作が入力される。入力装置４へ入力された操作情報は、ＣＰＵ１へ送られる。

ＲＯＭ３は、特定のエンディアン方式のプロセッサを実行対象として開発されたソフトウェア（コンパイル済みの実行プログラム）である開発対象プログラム３２と、開発対象プログラム３２からエンディアン依存箇所を検出するためのコンピュータプログラムであるソフトウェア開発プログラム３１と、が格納されている。

エンディアンとはメモリ上に複数バイトのデータを配置する方式であり、現在のほとんどのプロセッサはビッグエンディアンとリトルエンディアンのどちらかの方式をとっている。ソフトウェアがメモリ上のデータにアクセスする場合、データの先頭アドレスとアクセス単位（データ長）とを指定してメモリにアクセスを行う。ここで、メモリ上の同一箇所に対するアクセス単位が常に同じであれば、プロセッサのエンディアン方式に関係なくソフトウェアは正しく動作する。しかし、メモリ上の同一箇所に異なるアクセス単位でアクセスをしている場合、プロセッサのエンディアン方式が変わると誤動作する可能性がある。

図２は、開発対象プログラム３２の例を説明する図である。このプログラムは、１ワードが４バイト（３２ビット）で、ビッグエンディアン方式のプロセッサをターゲットとしたものである。図示するプログラムによれば、（１）の行において、ポインタ“arg”が指すワード（unsigned int）単位の領域にバイト（unsigned char）単位のデータ“tmp[0]”、“tmp[1]”、“tmp[2]”および“tmp[3]”を夫々書き込み位置をずらして書き込む。そして、（２）の行において、ポインタ“arg”が指すアドレスから２バイト目を読み出す。このプログラムは、ビッグエンディアンでは、（１）の行において“0x22”がポインタ“arg”が指すアドレスから２バイト目に書き込まれるため、（２）の行において“0x22”が読み出され、正しく動作するが、リトルエンディアンでは、（１）の行の実行時に“arg”が指すアドレスから２バイト目に“0x33”が書き込まれるため、正しく動作しない。

ソフトウェア開発プログラム３１は、開発対象プログラム３２を仮想的に実行（シミュレーション）するとともにメモリに対するアクセス命令の実行を監視し、上述の（１）および（２）によるメモリアクセスのように、メモリ上の同一の位置に対する異なるアクセス単位のアクセスが行われたとき、該位置にアクセスしたときに実行した命令（マシン語）をエンディアン依存箇所として検出する。

ＣＰＵ１は、ユーザによる入力装置４からの指示入力に従って、ＣＰＵ１がＲＯＭ３内からソフトウェア開発プログラム３１を読み出してＲＡＭ２内のプログラム格納領域に展開して実行することにより、次に説明するエンディアン依存箇所を検出するための各種機能を実現する。

図３は、ソフトウェア開発システム１００の機能構成を説明するブロック図である。図示するように、ソフトウェア開発システム１００は、ターゲットプロセッサの命令セットアーキテクチャを模擬する命令セットシミュレータ（Instruction Set Simulator；ＩＳＳ）２１と、ＩＳＳ２１により実行された命令がターゲットプロセッサのエンディアンに依存している命令コードであることを検出するチェッカ２４と、を備えている。

ＩＳＳ２１は、開発対象プログラム３２のターゲットプロセッサの挙動を模擬するＣＰＵモデル２２と、該ターゲットプロセッサが使用するメインメモリを模擬するメモリモデル２３とをさらに備えている。シミュレーション時には、開発対象プログラム３２がメモリモデル２３内にロードされる。そして、ＣＰＵモデル２２は、メモリモデル２３内にワークエリアを確保して、メモリモデル２３にロードされた開発対象プログラム３２を実行する。

なお、第１の実施の形態では、ＣＰＵモデル２２のターゲットプロセッサのエンディアン方式は開発対象プログラム３２のターゲットプロセッサのエンディアン方式と等しいものが用いられる。

チェッカ２４は、ＣＰＵモデル２２が実行する命令を監視し、同一箇所に対する書き込み時のデータ長と読み出し時のデータ長との相異を検出する。より詳しくは、チェッカ２４は、メモリモデル２３に対する書き込みを行う命令（メモリ書き込み命令）を実行したとき、書き込みのアクセス範囲（領域）をアクセス履歴テーブル２５に登録する。そして、チェッカ２４は、メモリモデル２３に対する読み出しを行う命令（メモリ読み出し命令）を実行したとき、アクセス履歴テーブル２５を検索して、読み出しアクセス対象のアクセス範囲がアクセス履歴テーブル２５に登録されているアクセス範囲と同一のアクセス範囲であるか否かを判定する。チェッカ２４は、アクセス範囲が異なるとき、実行した命令をエンディアン依存箇所として通知する。ここでは、チェッカ２４は、エンディアン依存箇所をファイルや表示装置５などにレポート出力することとする。

図４は、アクセス履歴テーブル２５のデータ構造例を説明する図である。図示するように、書き込み毎に書き込みアクセス先の領域の先頭アドレスと末尾アドレスとが記録されている。

開発対象プログラム３２が含むローカル変数は、プログラムの実行位置がそのスコープから抜ければ無効になるため、アクセス履歴テーブル２５からそのローカル変数に割り当てられたアドレスを削除する必要がある。チェッカ２４は、ＣＰＵモデル２２がスタックをポップする命令を実行したとき、ポップされたアドレスを含むエントリをアクセス履歴テーブル２５から削除する。

なお、ＣＰＵモデル２２は、実行対象の命令をＣＰＵモデル２２が含む命令レジスタに逐次取り込んで、命令レジスタに格納されている命令を実行する。したがって、チェッカ２４は、命令レジスタの中身を監視することによって命令の実行を監視するようにするとよい。また、プログラムカウンタが指すアドレスを監視することによって命令の実行を監視することもできる。また、スタックがポップされるとき、ＣＰＵモデル２２が含むスタックポインタの操作が実行される。チェッカ２４は、命令レジスタの中身やプログラムカウンタが指すアドレスを監視する以外に、スタックポインタを監視することによって、ポップする命令が実行されたことを検知することもができる。

図５は、ソフトウェア開発システム１００の動作を説明するフローチャートである。なお、開発対象プログラム３２の例として図２に示したプログラムをコンパイルしたものを用いて説明する。ＩＳＳ２１および開発対象プログラム３２のターゲットプロセッサはビッグエンディアン方式とする。また、開発対象プログラム３２のターゲットプロセッサは、１ワードは４バイト（３２ビット）であるものとし、ワード単位とバイト単位のロード・ストア命令をもつものとしている。例えば、コンパイラは、図２の（１）の行からワード単位のストア命令を生成し、図１の（２）の行からは、８ビット同士の代入であるからバイト単位のロード、ストア命令を生成する。また、ターゲットプロセッサは、アドレスが低位な方に向かってスタックを積み上げるものとする。そして、チェッカ２４はスタックポインタを監視し、スタックポインタの値の増加によってポップの実行を検知するものとする。

開発対象プログラム３２のシミュレーションがスタートすると、ＣＰＵモデル２２は、メモリモデル２３にロードされている開発対象プログラム３２が含む命令を順次実行する。図５に示すように、ＣＰＵモデル２２が命令を１つフェッチして実行すると（ステップＳ１）、チェッカ２４は、実行した命令がメモリ書き込み命令であるか否かを判定する（ステップＳ２）。メモリ書き込み命令には、ストア命令のほかに、プッシュ命令がある。実行した命令がメモリ書き込み命令であった場合（ステップＳ２、Ｙｅｓ）、チェッカ２４は、書き込み先が既にアクセス履歴テーブル２５に登録済みであるか否かをさらに判定する（ステップＳ３）。アクセス履歴テーブル２５に未登録であった場合（ステップＳ３、Ｎｏ）、チェッカ２４は書き込み先のアクセス範囲をアクセス履歴テーブル２５に登録し（ステップＳ４）、ステップＳ１に移行する。アクセス先がアクセス履歴テーブル２５に登録済みであった場合（ステップＳ３、Ｙｅｓ）、ステップＳ４をスキップしてステップＳ１に移行する。

ＣＰＵモデル２２は図２のプログラムの（１）の行が実行箇所となったとき、ワード単位のストア命令を実行する。このとき（１）の行のポインタ“arg”はメモリモデル２３上のアドレス“0x1000”に割り当てられていたとする。ここでのストア命令によるアクセスは“0x1000”に対するワード書き込みアクセスであり、アクセス範囲は“0x1000”〜“0x1003”となる。チェッカ２４は、ステップＳ４において、先頭アドレスを“0x1000”とし、末尾アドレスを“0x1003”としたエントリをアクセス履歴テーブル２５に登録する。なお１バイトの書き込みアクセスであれば先頭アドレスと末尾アドレスとは同一アドレスとなる。

ステップＳ２において、実行した命令がメモリ書き込み命令ではなかった場合（ステップＳ２、Ｎｏ）、チェッカ２４は、実行した命令がメモリ読み出し命令であったか否かを判定する（ステップＳ５）。メモリ読み出し命令には、ストア命令のほかに、ポップ命令がある。実行した命令がメモリ読み出し命令であった場合（ステップＳ５、Ｙｅｓ）、チェッカ２４は、アクセス先が既にアクセス履歴テーブル２５に登録済みであるか否かをさらに判定する（ステップＳ６）。読み出し先がアクセス履歴テーブル２５に登録済みであった場合（ステップＳ６、Ｙｅｓ）、チェッカ２４は、読み出し先のアクセス範囲がアクセス履歴テーブル２５に登録されているエントリと一致するか否かをさらに判定する（ステップＳ７）。読み出し先のアクセス範囲がアクセス履歴テーブル２５に登録されているエントリと一致していなかった場合（ステップＳ７、Ｎｏ）、チェッカ２４は、実行した命令をエンディアン依存箇所としてレポート出力する（ステップＳ８）。

ＣＰＵモデル２２は図２のプログラムの（２）の行が実行箇所となったとき、バイト単位のロード命令を実行する。このとき“tmp”は“arg”と同じ“0x1000”を指し、“tmp[1]”は“0x1001”に格納されている値を示すため、“0x1001”へのバイト単位のロード命令となる。すると、（１）の行の実行時に登録した“0x1000”〜“0x1003”と今回のアクセス先“0x1001”は重複するため、チェッカ２４はステップＳ６において読み出し先“0x1001”は登録済みと判定する。そして、読み出し先のアクセス範囲が“0x1001”であり、登録されているアクセス範囲が“0x1000”〜“0x1003”であるので、チェッカ２４はステップＳ７においてアクセス範囲が一致しないと判定し、ステップＳ８において、開発対象プログラム３２における（２）の行が実行箇所となったときに実行したロード命令をエンディアン依存箇所としてレポート出力する。

ステップＳ５において、実行した命令がメモリ読み出し命令ではなかった場合（ステップＳ５、Ｎｏ）、チェッカ２４は、スタックポインタの値が増加したか否かを判定する（ステップＳ９）。なお、ステップＳ６において読み出し先が未登録であった場合（ステップＳ６、Ｎｏ）や、ステップＳ７において読み出し先のアクセス範囲が登録されているエントリと一致した場合（ステップＳ７、Ｙｅｓ）や、ステップＳ８の後、ステップＳ９に移行する。

スタックポインタの値が増加した場合（ステップＳ９、Ｙｅｓ）、チェッカ２４は、アクセス履歴テーブル２５からポップされたアドレスに対応するエントリを削除し（ステップＳ１０）、ステップＳ１へ移行する。スタックポインタの値が増加していない場合（ステップＳ９、Ｎｏ）、ステップＳ１０をスキップしてステップＳ１へ移行する。

なお、ここでは、図２の開発対象プログラム３２によって、先にワード単位の書き込みが行われ、後にバイト単位の読み出しが行われたとき、エンディアン依存箇所として検出するようにしたが、先にバイト単位の書き込みが行われ、後にワード単位の読み出しが行われる場合でも同様の手順でエンディアン依存箇所として検出する。また、アクセス単位は、ワード単位とバイト単位とだけに限定されない。

また、オペコード内の即値はＣＰＵモデル２２内のレジスタに直接格納されるため、エンディアンに依存しない。値が利用されるときはストア命令によりメモリモデル２３へ転送されるため、エンディアン依存コードであれば上述の手順で検出できる。即値を使う命令へ変換される初期値つきローカル変数を利用したエンディアン依存コードは上述の手順で検出できる。

また、第１の実施の形態では、開発対象プログラム３２とＣＰＵモデル２２のエンディアン方式を同一のものとしているので、開発対象プログラム３２を最後まで実行することができるため、チェッカ２４は開発対象プログラム３２の実行パス上の全てのエンディアン依存箇所を出力することができる。ユーザは、レポート出力された箇所を修正することによって、別のエンディアン（ここではリトルエンディアン）方式のプロセッサをターゲットとしたプログラムに移植することができる。

なお、近年、コンパイラやアセンブラなどを用いてプログラムを静的に解析し、エンディアン依存箇所を検出するツールがある。このようなツールによると、コンパイラやアセンブラはファイル単位で解析を行うため、例えば図２の開発対象プログラム３２が含む“funcO”が“main()”と別のファイルにある場合、“funcO”内のコードがエンディアン依存であることを検出することは困難である。本第１の実施の形態では、シミュレーションにより開発対象プログラム３２を動的に解析するので、開発対象プログラム３２が複数のファイルに分割されている場合であってもエンディアン依存箇所を検出することができる。

なお、本第１の実施の形態のソフトウェア開発システム１００で実行されるソフトウェア開発プログラム３１を、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供または配布するように構成しても良い。また、ソフトウェア開発プログラム３１を、ＲＯＭ３等に予め組み込んで提供するように構成してもよい。また、ソフトウェア開発プログラム３１を、ＣＤ−ＲＯＭや外付けのメモリデバイスなどに格納して提供するようにしてもよい。

以上述べたように、本発明の第１の実施の形態によれば、開発対象プログラム３２を模擬実行するＣＰＵモデル２２およびＣＰＵモデル２２のワークエリアとしてのメモリモデル２３を備えるＩＳＳ２１と、開発対象プログラム３２が含むメモリモデル２３に対するアクセス命令（メモリ書き込み命令、メモリ読み出し命令）の実行を監視し、同一箇所に対する書き込み時のデータ長と読み出し時のデータ長との相異を検出したとき、検出時の実行箇所をエンディアン依存箇所として通知するチェッカ２４と、を備えるように構成したので、開発対象プログラム３２が含むエンディアン依存箇所を検出することができるようになる。

また、チェッカ２４は、メモリモデル２３に対するメモリ書き込み命令毎の書き込み領域を記録するアクセス履歴テーブル２５を更新管理し、アクセス履歴テーブル２５に基づいて同一箇所に対する書き込み時のデータ長と読み出し時のデータ長との相異を検出する。そして、チェッカ２４は、ＣＰＵモデル２２によるスタックポインタの操作を監視し、スタックのポップを検出したとき、アクセス履歴テーブル２５からポップされた書き込み領域を削除する、ように構成したので、ポップが行われる毎にポップされた箇所にプッシュされていたデータに関するアクセス履歴を消去できるので、スタック領域に対するメモリアクセスにかかるエンディアン依存箇所を検出できるようになる。

（第２の実施の形態）
第１の実施の形態では、開発対象プログラムとＣＰＵモデルとが同一のエンディアン方式である場合について述べた。第２の実施の形態では、開発対象プログラムとＣＰＵモデルとがエンディアン方式が異なる場合について述べる。なお、第２の実施の形態のソフトウェア開発システムのハードウェア構成は第１の実施の形態と等しいので、ハードウェア構成に関する説明を省略する。なお、第２の実施の形態のソフトウェア開発システムに符号２００を付して第１の実施の形態と区別する。

図６は、第２の実施の形態のソフトウェア開発システム２００の機能構成を説明する図である。第１の実施の形態と等しい機能部には同一の符号を付し、詳細な説明を省略する。

図６に示すように、ソフトウェア開発システム２００は、ＣＰＵモデル２２およびメモリモデル２３を有するＩＳＳ２１と、アクセス履歴テーブル２５を有するチェッカ２４と、バイト入れ替え部２６と、を備えている。

バイト入れ替え部２６は、ＣＰＵモデル２２が実行する夫々の命令のバイト入れ替えを行う。また、バイト入れ替え部２６は、ワード単位のアクセスなどマルチバイトアクセス（マルチバイト書き込みおよびマルチバイト読み出し）を行う際、アクセスデータのバイト入れ替え（言い換えると、アクセス先のバイト入れ替え）を実行する。

なお、Ｉ／ＯやＤＭＡＣ（Direct Memory Access Controller）など、ＣＰＵ以外のハードウェア・リソースがメモリ上にリトルエンディアンのデータを配置した場合、バイト入れ替えを行うと誤動作してしまう。しかしＣＰＵはそのデータのバイト並びがどのエンディアン方式なのか知る手段がない。このような状況を回避するため、第２の実施の形態では、バイト入れ替え禁止領域をあらかじめ外部から与えられるものとする。バイト入れ替え部２６は、バイト入れ替え禁止領域を記憶するバイト入れ替え禁止領域保存部２７を備えている。

図７は、ソフトウェア開発システム２００の動作を説明するフローチャートである。図示するように、ＣＰＵモデル２２が命令を１つフェッチすると（ステップＳ２１）、バイト入れ替え部２６は、ＣＰＵモデル２２がフェッチした命令をバイト入れ替えする（ステップＳ２２）。そして、バイト入れ替え部２６は、フェッチした命令がマルチバイトアクセス命令であるか否かを判定する（ステップＳ２３）。

命令がマルチバイトアクセス命令ではなかった場合（ステップＳ２３、Ｎｏ）、ＣＰＵモデル２２は、命令を実行する（ステップＳ２４）。命令がマルチバイトアクセス命令であった場合（ステップＳ２３、Ｙｅｓ）、バイト入れ替え部２６は、アクセス先がバイト入れ替え禁止領域であるか否かをさらに判定する（ステップＳ２５）。アクセス先がバイト入れ替え禁止領域である場合（ステップＳ２５、Ｙｅｓ）、ステップＳ２４に移行する。アクセス先がバイト入れ替え禁止領域ではない場合（ステップＳ２５、Ｎｏ）、バイト入れ替え部２６はアクセス先のバイト入れ替えを行い、ＣＰＵ２１は命令を実行し、バイト入れ替えされたアクセス先にアクセスする（ステップＳ２６）。

ステップＳ２４の後およびステップＳ２６の後、チェッカ２４は、実行した命令がメモリ書き込み命令であるか否かを判定する（ステップＳ２７）。実行した命令がメモリ書き込み命令であった場合（ステップＳ２７、Ｙｅｓ）、チェッカ２４は、書き込み先が既にアクセス履歴テーブル２５に登録済みであるか否かをさらに判定する（ステップＳ２８）。アクセス履歴テーブル２５に未登録であった場合（ステップＳ２８、Ｎｏ）、チェッカ２４は書き込み先のアクセス範囲をアクセス履歴テーブル２５に登録し（ステップＳ２９）、ステップＳ２１に移行する。アクセス先がアクセス履歴テーブル２５に登録済みであった場合（ステップＳ２８、Ｙｅｓ）、ステップＳ２９をスキップしてステップＳ２１に移行する。

ステップＳ２７において、実行した命令がメモリ書き込み命令ではなかった場合（ステップＳ２７、Ｎｏ）、チェッカ２４は、実行した命令がメモリ読み出し命令であったか否かを判定する（ステップＳ３０）。実行した命令がメモリ読み出し命令であった場合（ステップＳ３０、Ｙｅｓ）、チェッカ２４は、アクセス先が既にアクセス履歴テーブル２５に登録済みであるか否かをさらに判定する（ステップＳ３１）。読み出し先がアクセス履歴テーブル２５に登録済みであった場合（ステップＳ３１、Ｙｅｓ）、チェッカ２４は、読み出し先のアクセス範囲がアクセス履歴テーブル２５に登録されているエントリと一致するか否かをさらに判定する（ステップＳ３２）。読み出し先のアクセス範囲がアクセス履歴テーブル２５に登録されているエントリと一致していなかった場合（ステップＳ３２、Ｎｏ）、チェッカ２４は、実行した命令をエンディアン依存箇所としてレポート出力する（ステップＳ３３）。

ステップＳ３０において、実行した命令がメモリ読み出し命令ではなかった場合（ステップＳ３０、Ｎｏ）、チェッカ２４は、スタックポインタの値が増加したか否かを判定する（ステップＳ３４）。なお、ステップＳ３１において読み出し先が未登録であった場合（ステップＳ３０、Ｎｏ）や、ステップＳ３２において読み出し先のアクセス範囲が登録されているエントリと一致した場合（ステップＳ３２、Ｙｅｓ）や、ステップＳ３３においてメモリ読み出し命令をエンディアン依存箇所としてレポート出力した後にも、ステップＳ３４に移行する。

スタックポインタの値が増加した場合（ステップＳ３４、Ｙｅｓ）、チェッカ２４は、アクセス履歴テーブル２５からポップされたアドレスに対応するエントリを削除し（ステップＳ３５）、ステップＳ２１へ移行する。スタックポインタの値が増加していない場合（ステップＳ３４、Ｎｏ）、ステップＳ３５をスキップしてステップＳ２１へ移行する。

なお、バイト入れ替え部２６によるバイト入れ替え機能を有効にするかどうかは、シミュレーション前にユーザからの指定により選択されるようにしてもよい。

以上述べたように、本発明の第２の実施の形態によれば、開発対象プログラム３２が含む命令に対してバイト入れ替えを行ってＣＰＵモデル２２に実行させるとともに、ＣＰＵモデル２２が実行する命令がマルチバイトのアクセス命令であるとき、マルチバイトのアクセス命令の実行時にアクセス先のバイト入れ替えを行うバイト入れ替え部２６をさらに備えるように構成したので、開発対象プログラム３２を作成するためのコンパイラとしてＣＰＵモデル２２と同一のエンディアン方式のＣＰＵをターゲットＣＰＵとしたコンパイラが入手できない場合や、開発対象プログラム３２を作成したコンパイラのターゲットＣＰＵと同一のエンディアン方式のＣＰＵモデル２２を入手できない場合であっても、開発対象プログラム３２を最後までシミュレーションでき、開発対象プログラム３２が含むエンディアン依存箇所を検出することができるようになる。

また、メモリモデル２３にバイト入れ替え禁止領域を設定することができるので、ＣＰＵ以外のハードウェア・リソースからのメモリ書き込みがある場合であっても開発対象プログラム３２を意図した通りにシミュレートすることができる。

なお、ＣＰＵ以外のハードウェア・リソースからの書き込みデータについては特に言及しなかったが、書き込みデータをユーザが初期値として与えるようにしてよい。この場合、ユーザは、メモリモデル２３におけるバイト入れ替え禁止領域に初期値をロードしておくことになる。

また、ＣＰＵ以外のハードウェア・リソースの動作を模擬するモデルを追加し、ユーザがこれらのリソースからの書き込みデータを初期値として用意することなく動作させることができるようにしてもよい。図８は、該ハードウェア・リソースの動作を模擬するモデルが追加された場合のソフトウェア開発システム２００の機能構成を説明する図である。図示するように、拡張インタフェース（Ｉ／Ｆ）モデル２８は、ＣＰＵ以外に使用されるハードウェア・リソースの動作を模擬する。拡張インタフェースモデル２８は、ＣＰＵモデル２２と協調して動作し、バイト入れ替え禁止領域に適宜アクセスを行う。

また、第２の実施の形態によれば、フェッチするときにターゲットのエンディアン方式に合わせてフェッチするため、第１の実施の形態と同じく即値を問題なく扱うことができる。

（第３の実施の形態）
図９は、開発対象プログラムの別の例を説明する図である。図示するように、（３）の行においてstatic変数の初期値が設定されている。そして、“main()”により呼び出されて使用される“funcO”が含む（４）の行において、前記初期値の先頭から２バイト目の読み出しが行われている。

上記のような初期値は、“.word”命令などのアセンブラに対する擬似命令によりメモリに設定される。つまり、コンパイラは、このような数値をストア命令によってメモリへ転送させるのではなく、メモリの初期値として最初から変数がマップされているアドレスにデータが配置されているものとしてバイナリコードを作成する。したがって、シンボル情報を含まないバイナリコードとなっている開発対象プログラムを見るだけでは、そのビット列がデータなのかコードなのか区別できない。また、データと認識できてもデータ長を特定することができない。

第３の実施の形態では、このようにメモリに設定される初期値（メモリ初期値データ）に関し、アクセス履歴テーブルと同じ形式でメモリ初期値データに関する情報を入力できるようにした。

第３の実施の形態のソフトウェア開発システムのハードウェア構成は第１の実施の形態と等しいので、ハードウェア構成に関する説明を省略する。なお、第３の実施の形態のソフトウェア開発システムに符号３００を付して第１の実施の形態と区別する。

図１０は、第３の実施の形態のソフトウェア開発システム３００の機能構成を説明する図である。第１の実施の形態と等しい機能部には同一の符号を付し、詳細な説明を省略する。図示するように、ソフトウェア開発システム３００は、ＣＰＵモデル２２およびメモリモデル２３を有するＩＳＳ２１と、アクセス履歴テーブル２５を有するチェッカ２４と、テーブル入力受付部２９と、を備えている。

ユーザは、メモリ初期値データに関するアクセス履歴テーブルを予め作成しておく。例えば、ユーザは、初期値がコンパイラやリンカを通してメモリに設定される過程でそれらのツールにデータ長や配置されたアドレスを出力させるようにし、出力されたデータ長およびアドレスを用いてメモリ初期値データに関するアクセス履歴テーブルを作成するとよい。ユーザは、開発対象プログラム３２のシミュレーションを開始する前に、入力装置４を操作して外部記憶装置（図示せず）などから前記作成したアクセス履歴テーブルを入力する。

テーブル入力受付部２９は、アクセス履歴テーブルの入力を受け付けて、入力されたアクセス履歴テーブルをチェッカ２４に登録する。

このように、第３の実施の形態によれば、擬似命令によりバイナリコードに埋め込まれる初期値に関するアクセス履歴テーブルを登録できるようにしたので、メモリ初期値データが存在する場合であっても第１の実施の形態と同様のシミュレーション動作でエンディアン依存箇所を検出できるようになる。

なお、以上の説明においては、第１の実施の形態のソフトウェア開発システムにテーブル入力受付部２９を設けた構成として説明しているが、第２の実施の形態のソフトウェア開発システムにテーブル入力受付部２９を設けるようにしてもよい。

１ ＣＰＵ、２ ＲＡＭ、３ ＲＯＭ、４ 入力装置、５ 表示装置、２１ ＩＳＳ、２２ ＣＰＵモデル、２３ メモリモデル、２４ チェッカ、２５ アクセス履歴テーブル、２６ バイト入れ替え部、２７ バイト入れ替え禁止領域保存部、２８ 拡張インタフェースモデル、２９ テーブル入力受付部、３１ ソフトウェア開発プログラム、３２ 開発対象プログラム、１００、２００、３００ ソフトウェア開発システム。

Claims (7)

1. 実行プログラムを模擬実行するＣＰＵモデルおよび前記ＣＰＵモデルのワークエリアとしてのメモリモデルを備える命令セットシミュレータと、
   前記実行プログラムが含む前記メモリモデルに対するアクセス命令の実行を監視し、同一箇所に対する書き込み時のデータ長と読み出し時のデータ長との相異を検出したとき、検出時の実行箇所をエンディアン依存箇所として通知するチェッカと、
   を備えることを特徴とするソフトウェア開発システム。
2. 前記チェッカは、前記メモリモデルに対するメモリ書き込み命令毎の書き込み領域を記録するアクセス履歴情報を更新管理し、前記アクセス履歴情報に基づいて同一箇所に対する書き込み時のデータ長と読み出し時のデータ長との相異を検出する、
   ことを特徴とする請求項１に記載のソフトウェア開発システム。
3. 前記チェッカは、前記ＣＰＵモデルによるスタックポインタの操作を監視し、ポップ操作を検出したとき、前記アクセス履歴情報から前記ポップされた書き込み領域の記録を削除する、
   ことを特徴とする請求項２に記載のソフトウェア開発システム。
4. 前記実行プログラムは、アセンブラに対する擬似命令により前記メモリモデルに設定される初期値を含み、
   前記初期値に関するアクセス履歴情報の入力を受け付ける情報受け付け部をさらに備える、
   ことを特徴とする請求項２に記載のソフトウェア開発システム。
5. 前記実行プログラムが含む命令に対してバイト入れ替えを行って前記ＣＰＵモデルに実行させるとともに、前記ＣＰＵモデルが実行する命令がマルチバイトのアクセス命令であるとき、前記マルチバイトのアクセス命令の実行時にアクセス先のバイト入れ替えを行うバイト入れ替え部をさらに備える、
   ことを特徴とする請求項１〜４の何れか一項に記載のソフトウェア開発システム。
6. 前記メモリモデルは、前記バイト入れ替え部によるバイト入れ替えを禁止するバイト入れ替え禁止領域が確保されている、
   ことを特徴とする請求項５に記載のソフトウェア開発システム。
7. 前記バイト入れ替え禁止領域にアクセスする、前記ＣＰＵモデルと異なるハードウェアモデルをさらに備える、
   ことを特徴とする請求項６に記載のソフトウェア開発システム。

Images