JP2004192604A - Device and method for developing embedded software - Google Patents
Device and method for developing embedded software Download PDFInfo
- Publication number
- JP2004192604A JP2004192604A JP2003117717A JP2003117717A JP2004192604A JP 2004192604 A JP2004192604 A JP 2004192604A JP 2003117717 A JP2003117717 A JP 2003117717A JP 2003117717 A JP2003117717 A JP 2003117717A JP 2004192604 A JP2004192604 A JP 2004192604A
- Authority
- JP
- Japan
- Prior art keywords
- module
- address
- vector table
- symbol
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Devices For Executing Special Programs (AREA)
- Stored Programmes (AREA)
Abstract
Description
【0001】
【発明の属する技術分野】
本発明は携帯電話などの組み込み型の小型情報処理機器の補助記憶装置、とくにフラッシュメモリ上へ配置するプログラムの開発装置および方法に関するものである。
【0002】
【従来の技術】
携帯電話などの組み込み型の小型情報処理機器上へのソフトウェアの開発は、コンパイラやリンカを利用してオブジェクトコードを生成し、このオブジェクトコードを機器上のフラッシュROMにダウンロードする手法をとることを特徴としている。ソフトウェアの修正があった場合は、そのソースコードのみ再度コンパイルし、再び全体をリンクするという手法をとる。
しかし、バグの修正などでソースコードの修正を行うと、一部の関数が小さくなったり大きくなったりとメモリのアドレスがずれることも多い。
【0003】
ここで、関数呼び出しなどジャンプで実現している場合は、オブジェクトコードのアドレス情報が変更されてしまう。アドレスを集めたテーブルから読み出す形にした場合はレジスタでアクセスするために前もって実行する命令コードが増えてしまうという欠点もある。また、通常のコンパイル、リンク手段では実現できないという問題もある。
【0004】
そこで、自動的に様々条件を判断しながら、ソフトウェアの変更時に備えたコードを出力する装置を得る必要がある。
例えば特許文献1「リンク処理装置」、特許文献2「プログラムリンケージ方式」、特許文献3「プログラムのコンパイル・リンク方式」に開示された技術においては、ベクタエントリテーブルを導入し、自動生成するようにすることにより、一部を修正しても全体としてアドレスが変わる部分は一部のみに限定され、全体をリンクしなおす必要がないという技術が開示されている。しかし、ここで開示されている技術では、各ファイル内で宣言している外部参照宣言部によりベクタエントリテーブルを作成しているので、モジュール化を複数段にするなど巨大なプログラムを扱う場合にはベクタエントリテーブルが大きくなりすぎたり、後からモジュール構成を変更するということができないという欠点がある。
【0005】
例えば、特許文献4「プログラム処理装置および記憶媒体」に開示された技術によれば、プログラムの各モジュールを最適配置するために未解決のシンボル情報の数を利用する技術が開示されている。しかしながら、ソフトウェアの更新時の移動などを考慮する場合、未解決シンボル即ち外部シンボルの数とはなんら関係ないのでソフトウェア更新時を考慮した解決策にはなってないという欠点がある。
また、特許文献5「再配置可能なアドインソフト管理システム」に開示されたアドインソフトのためにベクタテーブルなどを予め確保しておく技術においては、後から追加するソフトがあるわけではなく、修正するためのソフトウェアに領域が増加する場合にはその領域を有効には利用できるかもしれないが、想定していない関数が新たに追加された場合などには有効に利用できないという欠点がある。
【0006】
また、非特許文献1「携帯電話機のバグをユーザの手元で修正へ」(P.22,P.23)によれば、ソフトウェア更新時の更新ファイルを小さくする方法が開示されており、この中にソフトウェアを複数ブロックに分割し、そのブロックごとに差分を取る方式が示されているが、具体的な方法は示されておらず、目的も通信断のときに引き続き処理する方式であることと、メモリを節約できることが提案されているにすぎず、プログラムの差分が小さくなるという問題を十分に解決できているわけではない。
【0007】
【特許文献1】
特開昭63−234324号公報
【特許文献2】
特開平1−237832号公報
【特許文献3】
特開平7−110758号公報
【特許文献4】
特開平11−296379号公報
【特許文献5】
特開2000−322268号公報
【非特許文献1】
「携帯電話機のバグをユーザの手元で修正へ」日経エレクトロニクス、2002年3月25日号
【0008】
【発明が解決しようとする課題】
組み込みソフトウェアのバージョンアップ時には、ソフトウェア全体を置き換えるか、差分データを追加する方法が考えられるが、これには人手で対処する必要がある。工場等に設置された機器の場合は、点検などにあわせて行うこともできるが、携帯電話のような消費者向けの機器の場合は、人手で行うにしても、ユーザが自分で無線などの通信手段を利用して行ないたいという要求がある。そうしないと、メーカ、販売店などの人が改修する必要がある。しかしながら、改修作業を考えると、当然、無線上に流すデータ量を抑える必要がある。従来の技術ではデータの差分を小さくすることはできており、ある程度自動的に処理手順を行えるようにはなっているが、ソフトウェア開発時には開発者は多数おり、プログラム分割単位であるモジュール構成などは考えにくく、徐々に出来上がってくるにもかかわらず、単純な外部シンボル情報のみを見て判断しているにすぎず、開発時のコストがかかるという課題がある。
【0009】
この発明は上記の課題を解決するためになされたもので、一体化される組込みソフトウェアに対して分割を行ない、かつ分割されたモジュール間の参照をアドレスを固定した参照関係として、後の改修時には、全体の交換に代えて改修対象のモジュールのみを入れ換えればよいようにする。
【0010】
【課題を解決するための手段】
この発明に係る組込みソフトウェア開発装置は、命令列をコンパイルし、ソフトウェアを構成する複数のオブジェクトをリンクしてアドレスを固定した組込みプログラムを作成するソフトウェア開発装置において、
ソフトウェアを細分化してモジュールを設定して、このモジュール間にまたがってシンボル参照する関係を抽出するモジュール間参照関係抽出部と、
モジュール間参照関係にある被参照モジュールにおいて、他モジュールからシンボル参照される受け入れ参照アドレスを定めたテーブルを定め、かつ受け入れ参照アドレスと自モジュール内のシンボル参照先の実アドレスとを結びつけるベクタテーブル作成部と、
他モジュールからの被参照アドレスをベクタテーブルの受け入れ参照アドレスに書換えるベクタテーブル・シンボル情報作成部、とを備えた。
【0011】
この発明に係る組込みソフトウェア開発方法は、命令列をコンパイルし、ソフトウェアを構成する複数のオブジェクトをリンクしてアドレスを固定した組込みプログラムを作成するソフトウェア開発方法において、
上記ソフトウェアを細分化してモジュールを設定して、このモジュール間にまたがってシンボル参照する関係を抽出するモジュール間参照関係抽出ステップと、
上記モジュール間参照関係にある被参照モジュールにおいて、受け入れ参照アドレスを定めたジャンプテーブルを作成するベクタテーブル作成ステップと、
上記受け入れ参照アドレスと自モジュール内の他モジュールからのシンボル参照先の実アドレスとを結びつけるベクタテーブル結び付けステップと、
作成したモジュールの大きさを基にモジュールの領域を定めるステップと、
他モジュールからの被参照アドレスを上記ベクタテーブルの受け入れ参照アドレスに書換えるベクタテーブル・シンボル情報作成ステップ、とを備えた。
【0012】
【発明の実施の形態】
実施の形態1.
コンパクトなメモリ使用量とするため、またそれ自体で完結するため、組込みソフトウェアは全体を一体化して作成するのが常である。またその場合、ソフトウェアの部分担当者は、他の部分担当者との連携はその時点では考える必要はなく、あとでコンパイルされる。ところでこうした組込みソフトウェアにおいても、各部分で改修が生じた場合に、全体を入れかえるのは大変なので、改修対象の部分のみを入れ換えたい。
この実施の形態においては、一体化された組込みソフトウェアを、後の改修に伴う入れ換えが容易なように、モジュール化し、かつ一体化ソフトウェアにおける参照を、モジュール間の参照に置き換え、従って改修モジュールを入れ換えても、他のモジュールには影響が及ばない組込みソフトウェア、を生成する開発装置、または開発方法を説明する。
【0013】
以下に本発明の実施の形態を述べる。図1〜図5及び一般的な動作図である図12を用いて本発明の構成と動作を説明する。図1は、本発明における装置の構成と、それらが全体として行う、目的プログラムの生成手順を示したフロー図である。
図において、モジュール定義ファイルというのは、ユーザが作成した複数のファイルや関数からなるプログラムのソースファイル100であり、通常、管理者により作成されるものである。本発明に関係のあるモジュール定義ファイル101は、作成したソースファイルをモジュールに分割するためのユーザが指定する定義ファイルであり、本来プログラム間の関数呼び出し関係が最小になるように指定する方が良いファイルであるが、開発途上ではすぐに変わるため、変更可能なようにしておくべきファイルである。図2にその例を示し、どのアドレスでモジュールm0、m1等が分割されるかを指定している。コンパイラ120は従来からあるコンパイラと同じで、図12のステップ211で、ソースプログラムを解釈し、機械語命令に置き換えていくが、複数のプログラム間の関係となるアドレス解決はせずにシンボル情報としてもオブジェクトファイル内に格納しておく装置であり、プログラムごとにオブジェクトファイル111を出力する。
【0014】
リンカ121は、従来からあるリンカであり、図12のステップ212で、複数のオブジェクトファイル111から未解決のシンボル情報を解決してひとつのオブジェクトにしたリンク済みオブジェクトファイル112を生成し、リンク時に解決したシンボルの情報をシンボル情報ファイル113として出力する。また、アドレスが全部解決できなかった場合はエラーとし、どの部分が解決できなかったかを示す。このほか、従来のリンカでは、複数のオブジェクトファイルで、シンボル解決に足りないものがあっても、別の機会にリンカで解決したシンボル情報ファイルを入力として全体として解決することもできる。
【0015】
ユーザ指定モジュール間参照関係抽出部122は、ユーザが指定するモジュール定義ファイル101を入力として、ユーザが指定した部分プログラムの集合をひとつのモジュールとして、この間の参照関係のみをシンボル情報ファイル113の中から抽出して、モジュール間参照関係表114を出力する。
シンボル情報ファイル113の中から抽出して、モジュール間参照関係表114を出力する。図3はそれを説明する図であり、図3(a)はシンボル情報ファイル中のfunc_aがアドレス00000d04にあって、他の018f31eaを初めとする14個所のアドレスから参照されることを示している。モジュール間参照関係抽出部122は、これを上記で説明したように異なるモジュールから参照される関係のみを抽出する。この場合func_aはモジュール定義ファイル101を参照してモジュール0にあることを知り、図3(a)の14個所のうち、同一のモジュール0内の参照を除いて、他のモジュールからは6個所から参照されることを抽出し、外部定義する関数名を並べて、シンボルと、シンボルがあるアドレスと、参照されるアドレス、とを組にして、図3(b)のように出力する。
更に、関数の参照か、データの参照かは、参照元のアドレスの命令がジャンプ系の命令であれば関数参照とし、レジスタへのロード命令であればデータ参照であるとする。更にアセンブラレベルのプログラムであれば、データはサイズ情報の出力をするので、これを用いてサイズ情報があればデータ参照とする。
【0016】
命令参照ベクタテーブル作成部123は、モジュール間参照関係表114から、モジュール間の参照に関する関数の入り口を決まった位置に固定するための関数の入り口へのジャンプまたは関数の入り口のアドレスを保持する情報テーブルとしてベクタテーブル115を出力する。
図4はベクタテーブルの概念を説明する図であり、図4(a)は図3(b)のモジュール間参照関係表114を示しており、ベクタテーブル作成部123は、具体的には、この関係表からベクタテーブルとして固定の入口アドレスを先頭部分に設定した部分と、この分割されたモジュール内の実アドレスと設定した固定アドレスとを結びつけるジャンプ命令の記述を行ない、これらジャンプ命令列で構成される、図4(b)に示される出力をする。
【0017】
ベクタテーブル・シンボル情報作成部124は、上記ベクタテーブル115を入力として、他からこのモジュールの参照に関しては直接関数をコールするのではなく、上記ベクタテーブル115を経由してコールさせるために、シンボルを解決するときに利用するべきベクタテーブル向けシンボルファイル116を出力する。
図5(b)はベクタテーブル向けシンボルファイル116の概念を示す図である。即ち図5(a)に示されるベクタテーブルに対して、他のモジュールから参照される実アドレスに代えて、ベクタテーブルの受け入れ参照アドレスを指定する。図5の例では、参照受け入れアドレスはベクタテーブルのアドレス100番地にあって、ここには実アドレスd04番地に飛ぶ命令が入っており、その実アドレスd04番地に__func_0aの命令がある。
【0018】
このように指定すると、ベクタテーブル115に記載された固定の受け入れ参照アドレスには、実アドレスへジャンプする命令が入っているので、モジュール内の実アドレスにある関数を参照しに行く。
なお詳細には、分割したモジュールが改修等でメモリの使用領域が拡大することを予想して、各モジュールに余裕領域を付加したアドレスでモジュールを設定するので、設定アドレスと実アドレスは変更される。
この後、コンパイラ120と、リンカ121にこのデータをコンパイル、リンクさせて目的の一体化した組み込み用の目的プログラム117を得る。この際、自身のモジュールのシンボル未解決のオブジェクトとリンクし、リンクした結果のオブジェクトを同時に結合する。図5(c)はこの組込みソフトウェアの最終状態を示す図である。図5(c)の左側に示す従来の一体化組込みソフトウェアは、本実施の形態では、命令参照ベクタテーブル作成部123によるベクタテーブル115と、ベクタテーブル・シンボル情報作成部124によるベクタテーブル向けシンボルファイル116により、モジュールAを始めとする分割された各モジュールB,C等になる。更にそれらが連結されて、かつ各モジュールに余裕領域を設け、他モジュールからは先ず先頭のベクタテーブルの固定アドレスに参照される構造となる、図5(c)の右側に示す、一つの組込みソフトウェアになる。
【0019】
なお、上記の実施の形態において、ソースプログラムは、C言語やアセンブリ言語によるプログラム記述言語で書かれたものであってよく、その場合は参照関係出力部は、上記言語で書かれたテキストファイルの内容を見て参照関係を判断する。
また元のプログラムコードが関数呼び出し形式で書かれているか、またはアセンブリ言語のジャンプ命令で書かれているか、スタックへの退避命令で書かれているか、を判断する機能を持たせてもよい。
または、目的プログラム中の命令コードから参照関係を判定する機能を持たせてもよい。
【0020】
以上のような構成をすることにより、ユーザが定義した各モジュール間の関数の呼び出しはベクタテーブル経由となり、モジュール内の場合は、複数のプログラムの集まりで外部呼出し宣言がされていたとしてもモジュール内参照の扱いで直接ジャンプする形式となり、ベクタテーブルはモジュール間のみ参照だけで小さくすることができるとともに、呼び出し位置はモジュールの先頭で固定とできる。
【0021】
更に、一体化した組込みソフトウェアをモジュール化したので、ソフトウェアの改修があっても改修部分のモジュールのみを更新すればよいので、更新量が抑えられ、ユーザ等により容易に行なえる。
上記説明では、モジュール間参照関係出力部、ベクタテーブル作成部、ベクタテーブル・シンボル情報作成部をハードウェアで構成する例を説明したが、これらを汎用の計算機による機能ソフトウェアで構成し、同等ステップを持たせた開発方法としてもよい。
【0022】
上記実施の形態では、シンボル参照は関数の参照をする場合を説明したが、関数参照に代えてデータ参照をするプログラムに対して、モジュール化をする開発装置、または方法を説明する。
図6は、参照関係がデータである場合の開発装置構成と、生成手順を示す図である。図において図1の構成と異なる部分は、ベクタテーブル作成部とベクタテーブル・シンボル情報作成部に換えて、共通データ作成部を設けた構成となっている。
即ち参照関係がデータ参照である場合には、参照関数の演算機能が必要無く、単にデータが判ればよいので、これら参照されるデータ群を共通データとしてテーブル(表)にまとめればよい。
【0023】
図7(a)は、シンボル情報ファイル113がデータである場合の例を示す図であり、モジュール間参照関係抽出部122は参照がデータであると判定すると、図7(b)のモジュール間データ参照表(テーブル)510を、ベクタテーブル作成部にではなく、共通データ作成部502に出力する。この図7(b)の例では、モジュールm0の参照0aのデータが、実アドレスは00000d04にあり、他のモジュールの018f31e6等から参照されている。
共通データ作成部502は、図8(a)に示すモジュール間データ参照表510から、モジュール間のデータ参照に関するデータを共通データとし、データ構造を定義した図8(a)に示す共通データ511を出力する。
即ち共通にすべきデータが示されているので、その内容を共通データとしてまとめて固定アドレスを確保してそこにテーブルとして用意する。
【0024】
図6において、各ソフトウェアの部分担当者が作成したソースファイル100をコンパイラ120にかけてコンパイルし(図12の作業210、211)、リンカ121でリンク作業212を行なう。このとき対象としたソースプログラム外の関数参照や、外部からの参照を許可する部分に関しては、未解決であることを示すエラーのままで出力し、リンク済みオブジェクトファイル112とシンボル情報ファイル113を得る。
ステップ212では、前記ステップ211の出力であるアドレス未解決状態のオブジェクトファイルを繋ぎ合わせて、お互いのアドレスで解決できるものは解決し、リンク済みオブジェクトファイル112とシンボルの解決時に利用したシンボルとアドレスの参照関係を示すシンボル情報ファイル113を出力する。
また、アドレスが全部解決できなかった場合はエラーを発生し、どの部分が解決できなかったかを示す。
【0025】
上記得られたリンク済みオブジェクトファイル112とシンボル情報ファイル113に、モジュール分割を指定したモジュール定義ファイル101を用いて、モジュール間参照関係抽出部122がモジュール間データ参照表510を抽出する。
更に共通データ作成部502が共通データ511を作成する。
最後にベクタテーブル115とベクタテーブル向けシンボルファイル116、または共通データ(テーブル)511を用いてコンパイル・リンク処理を行って、目的とする組込み用一体化プログラム(目的プログラム)が得られる。
【0026】
以上のような構成をすることにより、ユーザが定義した各モジュール間の関数のデータ参照は共通データへの参照となり、モジュール内の場合は、複数のプログラムの集まりで外部参照宣言がされていたとしてもモジュール内参照の扱いで直接アクセスする形式となり、共通データはモジュール間のみ参照だけで小さくすることができるとともに、呼び出し位置はモジュールの先頭で固定とできる効果がある。また、頻繁に変更するデータは共通データとせず関数経由でのアクセスとすることにより、共通データ領域に持っていかないとともに、必ずこの関数を経由することによりデバッグもしやすくなる効果がある。
【0027】
また共通データは固定位置におかれるため、最終的にはソフトウェアを更新する際の差分量を抑えることができるとともに、開発時にはモジュールの指定変更を行うことにより、容易に構成変更を行うことができる。
【0028】
図1の構成において、ベクタテーブル作成部はベクタテーブル115の作成に際してその領域については言及しなかった。しかし後のソフトウェア改修を考えれば、空き領域を設けておくことが望ましい。
この空き領域を各モジュールの量に比例して設けて、各モジュール毎の改修に対処してもよいし、あるいは全体として共通の空き領域を確保して、ソフトウェアの改修が発生すると、この共通の空き領域を使用するようにしてもよい。
【0029】
実施の形態2.
実施の形態1ではメモリの種類について触れなかったが、一般的に組込み機器は複数の異なる特性をもつメモリ、例えばフラッシュROMやSRAM、擬似SRAM等から構成される。実施の形態2では複数のメモリを考慮した開発装置について説明する。
本実施の形態における装置の構成と目的プログラムの生成手順は、図1に示す実施の形態1と同じである。以下では実施の形態1と異なる部分についてのみ図9、図10、図11を用いて説明する。なお、組込み機器のメモリはフラッシュROM(以下、ROM)とSRAM(以下、RAM)から構成されているものとする。
【0030】
モジュール定義ファイル101には、モジュールの情報とともに組込み機器を構成するメモリのアドレス情報も記載する。図2にその例を示し、2種類のメモリRAMとROMのアドレスの範囲を示している。この情報を元にシンボルがRAMに配置されているか、ROMに配置されているかを判断することができる。
【0031】
実施の形態2では、命令参照ベクタテーブル作成部123はモジュール定義ファイル101とモジュール間参照関係表114から、ベクタテーブル115の代わりに、図9に示すRAM用ベクタテーブル115AとROM用ベクタテーブル115Bの2種類のベクタテーブルを作成する。
RAM用ベクタテーブル115AにはRAM上の関数シンボルへのジャンプ命令、ROM用ベクタテーブル115BにはROM上の関数シンボルへのジャンプ命令が格納される。
【0032】
ベクタテーブル・シンボル情報作成部124は、上記ベクタテーブル115A、115Bを入力として、他からこのモジュールの参照に関しては直接関数をコールするのではなく、上記ベクタテーブル115Aもしくは115Bを経由してコールさせるために、シンボルを解決する時に利用するベクタテーブル向けシンボルファイル116’を図10のように出力する。
また、実施の形態2では、コンパイラ120とリンカ121を用いて目的プログラム117を得る際に、各モジュールのアドレス配置では、図11に示したように各モジュールのRAM領域、ROM領域のそれぞれに余裕領域を設けることで、メモリの使用領域の拡大に対応する。
【0033】
以上では関数参照の場合について説明したが、以下では関数参照に代えてデータ参照をするプログラムに対して、モジュール化をする場合について説明する。参照されるデータ群を共通データとしてテーブルにまとめる際、モジュール定義ファイル101のメモリのアドレス情報から、参照されるデータがどのメモリに配置されるかがわかるので、配置されるメモリの種類ごとに共通データのテーブルを作成する。これらの共通データテーブルは、固定アドレスを確保して配置するが、この際、共通データテーブルの配置先アドレスは、共通データが元々配置されていたメモリと同じメモリ上のアドレスとする。
【0034】
以上のような構成にすることにより、実施の形態1で示した開発装置を複数のメモリから構成される組込み機器のプログラムに適用することが可能になる。さらに、以上のような構成にすることで、モジュールのあるメモリ上での変更が発生した場合でも、そのモジュールの当該メモリの内容のみを変更すれば良いので、さらに更新量を抑えられる。
【0035】
【発明の効果】
以上のようにこの発明によれば、組込みソフトウェアの開発に際して、モジュール分割を行ない、このモジュール間参照関係を抽出し、ベクタテーブルを作成し、モジュール間参照のアドレスを解決したので、ソフトウェアの改修があっても、該当するモジュールのみの交換で対処できるソフトウェアを開発できる効果がある。
【図面の簡単な説明】
【図1】この発明の実施の形態1における開発装置の構成と目的プログラム生成の手順を示す図である。
【図2】実施の形態1におけるモジュール定義ファイルの例を示す図である。
【図3】実施の形態1におけるシンボル情報ファイルの例と、モジュール間参照関係表の例を示す図である。
【図4】実施の形態1におけるベクタテーブルの例を示す図である。
【図5】実施の形態1におけるベクタテーブル向けシンボルファイルの例と、目的プログラムの例を示す図である。
【図6】実施の形態1における開発装置の他の構成と目的プログラム生成の手順を示す図である。
【図7】実施の形態1におけるモジュール間データ参照表の例を示す図である。
【図8】実施の形態1における共通データ表の例を示す図である。
【図9】この発明の実施の形態2における2種類のベクタテーブルの例を示す図である。
【図10】実施の形態2におけるベクタテーブル向けシンボルファイルの例を示す図である。
【図11】実施の形態2における2種類のメモリに展開した目的プログラムの例を記す図である。
【図12】一般的なコンパイル・リンク手順を示す図である。
【符号の説明】
100 ソースファイル、101 モジュール定義ファイル、111 オブジェクトファイル、112 リンク済みオブジェクトファイル、113 シンボル情報ファイル、114 モジュール間参照関係表、115 ベクタテーブル、116 ベクタテーブル向けシンボルファイル、117 目的プログラム、120コンパイラ、121 リンカ、122 モジュール間参照関係抽出部、123ベクタテーブル作成部、124 ベクタテーブル・シンボル情報作成部、502 共通データ作成部、510 モジュール間データ参照表、511 共通データ。[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to an auxiliary storage device of a small embedded information processing device such as a mobile phone, and more particularly to an apparatus and method for developing a program to be arranged on a flash memory.
[0002]
[Prior art]
Software development on embedded small information processing devices such as mobile phones is characterized by using a method of generating object code using a compiler or linker and downloading this object code to a flash ROM on the device. And If the software is modified, only the source code is recompiled and the whole is linked again.
However, when the source code is corrected by, for example, fixing a bug, the address of the memory often shifts as some functions become smaller or larger.
[0003]
Here, when the function is realized by a jump such as a function call, the address information of the object code is changed. In the case of reading from a table in which addresses are collected, there is also a disadvantage that the number of instruction codes to be executed in advance increases in order to access by a register. There is also a problem that it cannot be realized by ordinary compiling and linking means.
[0004]
Therefore, it is necessary to obtain a device that outputs codes prepared when software is changed while automatically judging various conditions.
For example, in the techniques disclosed in
[0005]
For example, according to the technology disclosed in Patent Literature 4 “Program processing device and storage medium”, a technology is disclosed that utilizes the number of unresolved symbol information to optimally arrange each module of a program. However, there is a drawback that when considering the movement at the time of software update, there is no relation with the number of unresolved symbols, that is, the number of external symbols.
In addition, in the technique for previously securing a vector table or the like for add-in software disclosed in Patent Literature 5 “Relocatable add-in software management system”, there is no software to be added later, and correction is performed. May be used effectively when the area is increased in software for the purpose, but there is a disadvantage that it cannot be used effectively when an unexpected function is newly added.
[0006]
In addition, Non-Patent
[0007]
[Patent Document 1]
JP-A-63-234324
[Patent Document 2]
JP-A-1-237732
[Patent Document 3]
JP-A-7-110758
[Patent Document 4]
JP-A-11-296379
[Patent Document 5]
JP 2000-322268 A
[Non-patent document 1]
“To fix bugs in mobile phones at hand” Nikkei Electronics, March 25, 2002
[0008]
[Problems to be solved by the invention]
At the time of upgrading the embedded software, a method of replacing the entire software or adding difference data can be considered, but it is necessary to deal with this manually. In the case of equipment installed in factories, etc., it can be performed at the time of inspection, etc., but in the case of equipment for consumers such as mobile phones, even if it is done manually, the user himself or herself There is a request to use communication means. Otherwise, people such as manufacturers and dealers will need to renovate. However, in consideration of repair work, it is naturally necessary to reduce the amount of data transmitted over the radio. Conventional technology can reduce the difference in data and can perform the processing procedure to some extent automatically.However, when developing software, there are many developers, and the module configuration etc. Although it is difficult to imagine and it is gradually completed, the determination is made only by looking at simple external symbol information, and there is a problem that the cost at the time of development is high.
[0009]
The present invention has been made in order to solve the above-described problems, and performs division on embedded software to be integrated, and makes a reference between divided modules a reference relation in which an address is fixed. Instead of replacing the entire module, only the module to be repaired needs to be replaced.
[0010]
[Means for Solving the Problems]
An embedded software development device according to the present invention is a software development device that compiles an instruction sequence and links a plurality of objects constituting software to create an embedded program having a fixed address.
An inter-module reference relationship extraction unit for setting a module by subdividing software and extracting a relationship for symbol reference across the modules;
A vector table creating unit that defines a table that defines an acceptance reference address for symbol reference from another module in a referenced module in a module-to-module reference relationship, and links the acceptance reference address with a real address of a symbol reference destination in the own module. When,
A vector table / symbol information creating unit for rewriting a reference address from another module to an acceptance reference address of the vector table.
[0011]
An embedded software development method according to the present invention is a software development method for compiling an instruction sequence and linking a plurality of objects constituting software to create an embedded program having a fixed address.
An inter-module reference relationship extraction step of setting a module by subdividing the software and extracting a symbol reference relationship across the modules;
A vector table creating step of creating a jump table defining an accepting reference address in the referenced module in the inter-module reference relationship;
A vector table linking step of linking the accepted reference address with a real address of a symbol reference destination from another module in the own module;
Determining a module area based on the size of the created module;
A vector table / symbol information creating step of rewriting a referenced address from another module to an accepted reference address of the vector table.
[0012]
BEST MODE FOR CARRYING OUT THE INVENTION
In order to achieve a compact memory usage and complete itself, the embedded software is usually created as a whole. In such a case, the partial manager of the software does not need to consider the cooperation with other partial managers at that time, but is compiled later. By the way, even in the case of such embedded software, it is difficult to replace the entire part when a part is modified, so it is desirable to replace only the part to be modified.
In this embodiment, the integrated embedded software is modularized so that it can be easily replaced with a later modification, and the reference in the integrated software is replaced with a reference between modules, and therefore, the modified module is replaced. However, a development device or a development method for generating embedded software that does not affect other modules will be described.
[0013]
Hereinafter, embodiments of the present invention will be described. The configuration and operation of the present invention will be described with reference to FIGS. 1 to 5 and FIG. 12 which is a general operation diagram. FIG. 1 is a flow chart showing the configuration of the apparatus according to the present invention and the procedure for generating a target program performed by them as a whole.
In the drawing, a module definition file is a
[0014]
The
[0015]
The user-specified inter-module reference
It extracts from the symbol information file 113 and outputs an inter-module reference relation table 114. FIG. 3 is a diagram for explaining this, and FIG. 3A shows that func_a in the symbol information file is located at address 00000d04 and is referred to from other 14 addresses including 018f31ea. . The inter-module reference
Further, it is assumed that the function reference or the data reference is a function reference if the instruction of the reference source address is a jump-related instruction, and a data reference if the instruction is a load instruction to a register. Further, in the case of an assembler level program, data outputs size information. If there is size information, the data is referred to.
[0016]
The instruction reference
FIG. 4 is a diagram for explaining the concept of the vector table. FIG. 4A shows the inter-module reference relation table 114 of FIG. 3B. From the relation table, a description is made of a jump instruction linking a part where a fixed entry address is set as a head part as a vector table and a real address in the divided module and the set fixed address. The output shown in FIG.
[0017]
The vector table / symbol
FIG. 5B is a diagram showing the concept of the vector
[0018]
When specified in this manner, the fixed acceptance reference address described in the vector table 115 contains an instruction for jumping to the real address, so that the function at the real address in the module is referred to.
Note that in detail, the module is set with an address obtained by adding a margin area to each module in anticipation that the used area of the memory will be expanded due to repair or the like of the divided module, so the set address and the real address are changed .
Thereafter, this data is compiled and linked by the
[0019]
In the above embodiment, the source program may be written in a program description language such as C language or assembly language. In that case, the reference relation output unit outputs a text file written in the above language. See the contents to determine the reference relationship.
Further, a function may be provided for determining whether the original program code is written in a function call format, written in an assembly language jump instruction, or written in a stack save instruction.
Alternatively, a function of determining a reference relationship from an instruction code in a target program may be provided.
[0020]
With the above configuration, the function calls between the modules defined by the user are performed via the vector table. In the case of the module, even if the external call declaration is made in a group of multiple programs, the function is called in the module. The format is such that the jump is made directly by the handling of the reference, and the vector table can be reduced only by reference between modules, and the calling position can be fixed at the head of the module.
[0021]
Furthermore, since the integrated embedded software is modularized, only the module in the repaired part needs to be updated even if the software is modified, so that the amount of update is reduced and the user can easily perform the modification.
In the above description, an example in which the inter-module reference relation output unit, the vector table creation unit, and the vector table / symbol information creation unit are configured by hardware has been described. However, these are configured by functional software using a general-purpose computer, and equivalent steps are performed. It may be a development method provided.
[0022]
In the above-described embodiment, a case has been described where a symbol reference refers to a function. However, a description will be given of a development apparatus or a method that modularizes a program that refers to data instead of a function reference.
FIG. 6 is a diagram illustrating a configuration of a development device when the reference relationship is data, and a generation procedure. 1 differs from the configuration of FIG. 1 in that a common data generator is provided in place of the vector table generator and the vector table / symbol information generator.
That is, when the reference relationship is data reference, the operation function of the reference function is not required, and the data can be simply determined. Therefore, a group of these referenced data may be collected as a common data in a table.
[0023]
FIG. 7A is a diagram illustrating an example of a case where the symbol information file 113 is data. When the inter-module reference
The common
That is, since data to be shared is shown, the contents are put together as common data, a fixed address is secured, and a table is prepared there.
[0024]
In FIG. 6, a
In
If all addresses cannot be resolved, an error is generated, indicating which part could not be resolved.
[0025]
The inter-module reference
Further, the common
Finally, a compile / link process is performed using the vector table 115 and the
[0026]
With the above configuration, the data reference of the function between each module defined by the user becomes a reference to the common data, and in the case of the module, if the external reference declaration is made in a group of multiple programs Also has the effect that the common data can be reduced only by reference between modules, and the calling position can be fixed at the head of the module, by directly accessing by handling the reference within the module. In addition, since frequently changed data is not accessed as common data but is accessed via a function, the data is not brought to the common data area, and debugging is easily performed by always passing through this function.
[0027]
In addition, since the common data is located at a fixed position, the amount of difference when software is finally updated can be reduced, and the configuration can be easily changed by changing the designation of the module at the time of development. .
[0028]
In the configuration of FIG. 1, the vector table creation unit did not mention the area when creating the vector table 115. However, in consideration of later software modification, it is desirable to provide an empty area.
This free space may be provided in proportion to the amount of each module to deal with the repair for each module, or if a common free space is secured as a whole and software repair occurs, this common An empty area may be used.
[0029]
Although the type of the memory is not described in the first embodiment, the embedded device is generally configured of a memory having a plurality of different characteristics, for example, a flash ROM, an SRAM, and a pseudo SRAM. In the second embodiment, a development device considering a plurality of memories will be described.
The configuration of the device and the procedure for generating the target program in the present embodiment are the same as those in the first embodiment shown in FIG. Hereinafter, only portions different from the first embodiment will be described with reference to FIGS. 9, 10, and 11. It is assumed that the memory of the embedded device includes a flash ROM (hereinafter, ROM) and an SRAM (hereinafter, RAM).
[0030]
In the
[0031]
In the second embodiment, instead of the vector table 115, the instruction reference vector
A jump instruction to a function symbol on the RAM is stored in the RAM vector table 115A, and a jump instruction to a function symbol on the ROM is stored in the ROM vector table 115B.
[0032]
The vector table / symbol
In the second embodiment, when the
[0033]
Although the case of function reference has been described above, a case of modularizing a program that refers to data instead of function reference will be described below. When a group of data to be referred to is grouped as common data in a table, the memory address information of the
[0034]
With the above configuration, the development device described in the first embodiment can be applied to a program of an embedded device including a plurality of memories. Furthermore, with the above-described configuration, even when a change occurs in a memory where a module is located, only the contents of the memory of the module need be changed, so that the update amount can be further reduced.
[0035]
【The invention's effect】
As described above, according to the present invention, when developing embedded software, module division is performed, this inter-module reference relationship is extracted, a vector table is created, and the inter-module reference address is resolved. Even so, there is an effect that software that can be dealt with by replacing only the relevant module can be developed.
[Brief description of the drawings]
FIG. 1 is a diagram showing a configuration of a development device and a procedure for generating a target program according to
FIG. 2 is a diagram showing an example of a module definition file according to the first embodiment.
FIG. 3 is a diagram showing an example of a symbol information file and an example of an inter-module reference relation table in the first embodiment.
FIG. 4 is a diagram showing an example of a vector table according to the first embodiment.
FIG. 5 is a diagram showing an example of a vector table symbol file and an example of a target program in the first embodiment.
FIG. 6 is a diagram showing another configuration of the development device and a procedure of generating a target program according to the first embodiment.
FIG. 7 is a diagram showing an example of an inter-module data reference table according to the first embodiment.
FIG. 8 is a diagram showing an example of a common data table in the first embodiment.
FIG. 9 is a diagram showing an example of two types of vector tables according to the second embodiment of the present invention.
FIG. 10 is a diagram showing an example of a vector table symbol file according to the second embodiment.
FIG. 11 is a diagram illustrating an example of a target program developed in two types of memories according to the second embodiment.
FIG. 12 is a diagram showing a general compile / link procedure.
[Explanation of symbols]
Claims (11)
上記ソフトウェアを細分化してモジュールを設定して、該モジュール間にまたがってシンボル参照する関係を抽出するモジュール間参照関係抽出部と、
上記モジュール間参照関係にある被参照モジュールにおいて、他モジュールからシンボル参照される受け入れ参照アドレスを定めたテーブルを定め、かつ該受け入れ参照アドレスと自モジュール内の上記シンボル参照先の実アドレスとを結びつけるベクタテーブル作成部と、
他モジュールからの被参照アドレスを上記ベクタテーブルの受け入れ参照アドレスに書換えるベクタテーブル・シンボル情報作成部、とを備えたことを特徴とする組込みソフトウェア開発装置。In a software development device that compiles an instruction sequence and links a plurality of objects constituting software to create an embedded program with a fixed address,
An inter-module reference relation extraction unit that sets a module by subdividing the software, and extracts a relation of symbol reference across the modules;
A vector that defines a table that defines an acceptance reference address for symbol reference from another module in the referenced module in the inter-module reference relationship, and links the acceptance reference address with the real address of the symbol reference destination in the own module. A table creation unit,
A vector table / symbol information creating unit for rewriting an address to be referred from another module to an acceptance reference address of the vector table.
上記ソフトウェアを細分化してモジュールを設定して、該モジュール間にまたがってシンボル参照する関係を抽出するモジュール間参照関係抽出ステップと、上記モジュール間参照関係にある被参照モジュールにおいて、受け入れ参照アドレスを定めたジャンプテーブルを作成するベクタテーブル作成ステップと、
上記受け入れ参照アドレスと自モジュール内の他モジュールからのシンボル参照先の実アドレスとを結びつけるベクタテーブル結び付けステップと、
作成したモジュールの大きさを基にモジュールの領域を定めるステップと、
他モジュールからの被参照アドレスを上記ベクタテーブルの受け入れ参照アドレスに書換えるベクタテーブル・シンボル情報作成ステップ、とを備えたことを特徴とする組込みソフトウェア開発方法。In a software development method of compiling an instruction sequence and linking a plurality of objects constituting software to create an embedded program having a fixed address,
An inter-module reference relation extracting step of extracting a relation for symbol reference across the modules by subdividing the software and setting a module; and determining an accepting reference address in the referenced module having the inter-module reference relation. A vector table creating step for creating a jump table,
A vector table linking step of linking the accepted reference address with a real address of a symbol reference destination from another module in the own module;
Determining a module area based on the size of the created module;
A vector table / symbol information creation step of rewriting a reference address from another module to an acceptance reference address of the vector table.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003117717A JP3682050B2 (en) | 2002-10-15 | 2003-04-23 | Embedded software development equipment |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002300194 | 2002-10-15 | ||
JP2003117717A JP3682050B2 (en) | 2002-10-15 | 2003-04-23 | Embedded software development equipment |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2004192604A true JP2004192604A (en) | 2004-07-08 |
JP3682050B2 JP3682050B2 (en) | 2005-08-10 |
Family
ID=32774359
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003117717A Expired - Fee Related JP3682050B2 (en) | 2002-10-15 | 2003-04-23 | Embedded software development equipment |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3682050B2 (en) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006277615A (en) * | 2005-03-30 | 2006-10-12 | Denso Corp | Automobile control unit |
JP2007094577A (en) * | 2005-09-27 | 2007-04-12 | Sumitomo Heavy Ind Ltd | Built-in control method, management device, built-in control device, and built-in control system |
JP2009211193A (en) * | 2008-02-29 | 2009-09-17 | Nec Electronics Corp | Microcomputer, embedded program, and embedded program creation method |
JP2009288858A (en) * | 2008-05-27 | 2009-12-10 | Fuji Xerox Co Ltd | Additional executable information generation device, information processor, and program |
-
2003
- 2003-04-23 JP JP2003117717A patent/JP3682050B2/en not_active Expired - Fee Related
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006277615A (en) * | 2005-03-30 | 2006-10-12 | Denso Corp | Automobile control unit |
JP4501159B2 (en) * | 2005-03-30 | 2010-07-14 | 株式会社デンソー | Automotive control unit |
JP2007094577A (en) * | 2005-09-27 | 2007-04-12 | Sumitomo Heavy Ind Ltd | Built-in control method, management device, built-in control device, and built-in control system |
JP4757589B2 (en) * | 2005-09-27 | 2011-08-24 | 住友重機械工業株式会社 | Embedded control method, management apparatus, embedded control apparatus, and embedded control system |
JP2009211193A (en) * | 2008-02-29 | 2009-09-17 | Nec Electronics Corp | Microcomputer, embedded program, and embedded program creation method |
JP2009288858A (en) * | 2008-05-27 | 2009-12-10 | Fuji Xerox Co Ltd | Additional executable information generation device, information processor, and program |
Also Published As
Publication number | Publication date |
---|---|
JP3682050B2 (en) | 2005-08-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6795963B1 (en) | Method and system for optimizing systems with enhanced debugging information | |
US5675803A (en) | Method and apparatus for a fast debugger fix and continue operation | |
US5546586A (en) | Method and apparatus for vectorizing the contents of a read only memory device without modifying underlying source code | |
JP2006092544A (en) | Dynamic link of module in pre-operating system environment | |
US20070011669A1 (en) | Software migration | |
US20070220496A1 (en) | Multiple operating device version software generating device and multiple operating device version software generation support program and method | |
CN105159732B (en) | In mobile terminal installation or the method and mobile terminal of more new application | |
JPH0836488A (en) | Method and device for checking run-time error using dynamic patching | |
CN110059456B (en) | Code protection method, code protection device, storage medium and electronic equipment | |
US20110126179A1 (en) | Method and System for Dynamic Patching Software Using Source Code | |
CN106648755B (en) | Method and device for dynamically loading dex in android art environment | |
CN112882718A (en) | Compiling processing method, device, equipment and storage medium | |
US20060041873A1 (en) | Computer system and method for verifying functional equivalence | |
CN116934330A (en) | Method for calling intelligent contract, executing method, computer equipment and storage medium | |
US7458071B2 (en) | Compilation method, compiler apparatus and compiler | |
CN111367512B (en) | Method and device for creating Android library module dependency relationship in application development | |
JP3682050B2 (en) | Embedded software development equipment | |
KR20060035077A (en) | Data processing device and register allocation method using data processing device | |
KR100478463B1 (en) | Dynamic Linking Method for Application Program | |
JP3266097B2 (en) | Automatic reentrant method and system for non-reentrant program | |
CN113220327A (en) | Intelligent contract upgrading method and block chain system | |
CN115167862A (en) | Patch method and related equipment | |
CN117234953B (en) | Kernel debugging method based on shadow code cache | |
CN116243971B (en) | Static dependency bootstrapping-based kernel-independent module construction method | |
JP2002259121A (en) | Source line debagging device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040406 |
|
A871 | Explanation of circumstances concerning accelerated examination |
Effective date: 20040406 Free format text: JAPANESE INTERMEDIATE CODE: A871 |
|
A975 | Report on accelerated examination |
Effective date: 20040419 Free format text: JAPANESE INTERMEDIATE CODE: A971005 |
|
RD04 | Notification of resignation of power of attorney |
Effective date: 20040519 Free format text: JAPANESE INTERMEDIATE CODE: A7424 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040608 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040722 |
|
RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20041025 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050308 |
|
A521 | Written amendment |
Effective date: 20050414 Free format text: JAPANESE INTERMEDIATE CODE: A523 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Effective date: 20050517 Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Effective date: 20050519 Free format text: JAPANESE INTERMEDIATE CODE: A61 |
|
R150 | Certificate of patent (=grant) or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Year of fee payment: 3 Free format text: PAYMENT UNTIL: 20080527 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Year of fee payment: 4 Free format text: PAYMENT UNTIL: 20090527 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Year of fee payment: 5 Free format text: PAYMENT UNTIL: 20100527 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100527 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Year of fee payment: 6 Free format text: PAYMENT UNTIL: 20110527 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110527 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120527 Year of fee payment: 7 |
|
LAPS | Cancellation because of no payment of annual fees |