JP2004192604A - Device and method for developing embedded software - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To create software with which only a module to be upgraded can be replaced in the case of subsequent upgrade by dividing embedded software to be integrated and making reference between divided modules as reference relation to which the addresses are fixed. <P>SOLUTION: The device for developing embedded software is provided with an inter-module reference relation extraction part 122 which sets modules by subdividing the software and extracts relation for performing symbol reference between the modules, a vector table creation part 123 which determines a table in which an acceptance reference address to which the symbol reference is performed from the other module is determined and couples the acceptance reference address with an actual address of a symbol reference destination in the present module in a module to be referred in inter-module reference relation, and a vector table/symbol information creation part 124 which rewrites the address to be referred from the other module to the acceptance reference address of the vector table. <P>COPYRIGHT: (C)2004,JPO&NCIPI

Description

[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 Patent Literature 1 “Link processing device”, Patent Literature 2 “Program linkage method”, and Patent Literature 3 “Compile / link method of program”, a vector entry table is introduced and automatically generated. Thus, a technique is disclosed in which even if a part is corrected, the part where the address changes as a whole is limited to only a part, and it is not necessary to relink the whole. However, in the technology disclosed here, since the vector entry table is created by the external reference declaration section declared in each file, when handling a large program such as modularizing multiple stages, There are drawbacks in that the vector entry table becomes too large or that the module configuration cannot be changed later.
[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 Document 1 “Fix bugs in mobile phones at hand” (P.22, P.23) discloses a method of reducing an update file at the time of software update. Describes a method in which software is divided into multiple blocks and the difference is taken for each block.However, no specific method is described, and the purpose is to continue processing when communication is interrupted. However, it is merely proposed that the memory can be saved, but the problem that the difference between the programs becomes small cannot be sufficiently solved.
[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
Embodiment 1 FIG.
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 source file 100 of a program including a plurality of files and functions created by a user, and is usually created by an administrator. The module definition file 101 related to the present invention is a definition file specified by a user for dividing the created source file into modules, and it is better to specify the module definition file so as to minimize the function call relationship between programs. It is a file, but it should be able to change because it changes quickly during development. FIG. 2 shows an example in which the addresses at which the modules m0, m1, etc. are divided are specified. The compiler 120 is the same as a conventional compiler. In step 211 in FIG. 12, the source program is interpreted and replaced with machine language instructions. Is also stored in an object file, and outputs an object file 111 for each program.
[0014]
The linker 121 is a conventional linker. In step 212 of FIG. 12, the unresolved symbol information is resolved from the plurality of object files 111 to generate a linked object file 112 which is made into one object, and is resolved at the time of linking. The information of the symbol thus output is output as a symbol information file 113. If all the addresses could not be resolved, it is regarded as an error, and indicates which part could not be resolved. In addition, in the conventional linker, even if a plurality of object files are insufficient for symbol resolution, the symbol information file resolved by the linker at another occasion can be input and resolved as a whole.
[0015]
The user-specified inter-module reference relation extraction unit 122 receives the module definition file 101 specified by the user as an input, sets a set of partial programs specified by the user as one module, and extracts only the reference relation between the modules from the symbol information file 113. It extracts and outputs the inter-module reference relation table 114.
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 relation extracting unit 122 extracts only the relations referred to from different modules as described above. In this case, it is known that func_a is in module 0 by referring to the module definition file 101, and from among 14 locations in FIG. A reference is extracted, and a function name to be externally defined is arranged, and a set of a symbol, an address where a symbol is located, and an address to be referenced is output as shown in FIG. 3B.
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 vector table creator 123 jumps to the function entry or fixes the address of the function entry for fixing the entry of the function relating to the reference between modules from the inter-module reference relationship table 114. The vector table 115 is output as a table.
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 information creating unit 124 receives the vector table 115 as an input, and calls a function via the vector table 115 instead of directly calling a function for reference to this module from another. A vector table symbol file 116 to be used when solving is output.
FIG. 5B is a diagram showing the concept of the vector table symbol file 116. That is, for the vector table shown in FIG. 5A, an acceptance reference address of the vector table is specified instead of a real address referred to from another module. In the example of FIG. 5, the reference acceptance address is at address 100 of the vector table, and contains an instruction for jumping to the real address d04. At the real address d04, there is an instruction of __func_0a.
[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 compiler 120 and the linker 121 to obtain the integrated target program 117 for integration. At this time, the object is linked with the object of the module whose symbol has not been resolved, and the linked object is simultaneously combined. FIG. 5C shows the final state of the embedded software. In the present embodiment, the conventional integrated embedded software shown on the left side of FIG. 5C is a vector table 115 by the instruction reference vector table creation unit 123 and a vector table symbol file by the vector table / symbol information creation unit 124. By 116, each of the divided modules B and C including the module A is obtained. Further, they are connected to each other and a margin area is provided in each module, and other modules first have a structure referred to by the fixed address of the first vector table. One embedded software shown on the right side of FIG. become.
[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 relationship extracting unit 122 determines that the reference is data, the inter-module reference data extraction unit 122 illustrated in FIG. The reference table (table) 510 is output not to the vector table creation unit but to the common data creation unit 502. In the example of FIG. 7B, the data of the reference 0a of the module m0 has the real address of 00000d04, and is referred to by 018f31e6 of another module.
The common data creation unit 502 uses the data related to data reference between modules as common data from the inter-module data reference table 510 illustrated in FIG. 8A, and converts the common data 511 illustrated in FIG. Output.
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 source file 100 created by a person in charge of each software is compiled by a compiler 120 (operations 210 and 211 in FIG. 12), and a link operation 212 is performed by a linker 121. At this time, the function reference outside the target source program and the portion permitted to be referred from outside are output as an error indicating that they are unresolved, and the linked object file 112 and the symbol information file 113 are obtained. .
In step 212, the object files in the address unresolved state output from the step 211 are connected to resolve the one that can be resolved by their addresses, and the linked object file 112 and the symbol and the address used in resolving the symbol are used. The symbol information file 113 indicating the reference relationship is output.
If all addresses cannot be resolved, an error is generated, indicating which part could not be resolved.
[0025]
The inter-module reference relation extraction unit 122 extracts the inter-module data reference table 510 from the obtained linked object file 112 and symbol information file 113 by using the module definition file 101 specifying the module division.
Further, the common data creation unit 502 creates the common data 511.
Finally, a compile / link process is performed using the vector table 115 and the symbol file 116 for the vector table, or the common data (table) 511 to obtain a target integrated program for integration (target program).
[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]
Embodiment 2 FIG.
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 module definition file 101, the address information of the memory constituting the embedded device is described together with the module information. FIG. 2 shows an example of this, and shows the address ranges of two types of memory RAM and ROM. Based on this information, it can be determined whether the symbols are arranged in the RAM or the ROM.
[0031]
In the second embodiment, instead of the vector table 115, the instruction reference vector table creation unit 123 replaces the RAM vector table 115A and the ROM vector table 115B shown in FIG. Create two types of vector tables.
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 information creation unit 124 receives the above-mentioned vector tables 115A and 115B as inputs, and does not directly call a function for referring to this module from the other, but makes a call via the vector table 115A or 115B. Next, a vector table symbol file 116 'used for symbol resolution is output as shown in FIG.
In the second embodiment, when the target program 117 is obtained by using the compiler 120 and the linker 121, the address arrangement of each module has a margin in the RAM area and the ROM area of each module as shown in FIG. By providing the area, it is possible to cope with the expansion of the use area of the memory.
[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 module definition file 101 indicates which memory the data to be referred to is allocated. Create a table of data. These common data tables are arranged with a fixed address secured. At this time, the arrangement destination address of the common data table is an address on the same memory as the memory where the common data was originally arranged.
[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 Embodiment 1 of the present invention.
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]
Reference Signs List 100 source file, 101 module definition file, 111 object file, 112 linked object file, 113 symbol information file, 114 inter-module reference relation table, 115 vector table, 116 symbol file for vector table, 117 target program, 120 compiler, 121 Linker, 122 inter-module reference relationship extraction unit, 123 vector table creation unit, 124 vector table / symbol information creation unit, 502 common data creation unit, 510 inter-module data reference table, 511 common data.

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 place of the vector table creation unit, if the contents referred to by a symbol from another module in the referenced module in the inter-module reference relationship are data, common data creation that collects the referenced data and creates common data The embedded software development device according to claim 1, further comprising a unit. 2. The embedded software development apparatus according to claim 1, wherein the development apparatus allocates a margin area according to the size of each module when assigning an address to the area of each module. 2. The embedded software development apparatus according to claim 1, wherein the development apparatus provides a common margin area when assigning an address to each module area. The inter-module reference relation extracting unit determines that the data reference is a data reference based on whether a load instruction to a register or outputs size information, and otherwise determines a function reference. The embedded software development device according to claim 1, wherein 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. In place of the vector table creation step, if the contents referred to by a symbol from another module are data in a referenced module having a reference relation between modules, common data creation for collecting the referenced data and creating common data The embedded software development method according to claim 6, further comprising a step. In the inter-module reference relation extraction step, it is determined that a data reference is made based on whether a load instruction to a register or size information is output, and otherwise, a function reference is determined. The embedded software development method according to claim 6. When there are a plurality of types of memories for storing the program, the vector table creation unit sets the area of the vector table of the module in the same memory as the real address of the module when a predetermined memory is allocated to the module. The embedded software development device according to claim 1, wherein: When there are a plurality of types of memories for storing programs, the common data creation unit allocates the same memory as the original memory before division when allocating a predetermined memory to a certain common data area. 3. The embedded software development device according to claim 2, wherein: 2. The embedded software development apparatus according to claim 1, wherein the development apparatus assigns a spare area to each of the memories when there are a plurality of types of memories for storing programs or common data.

Images