JP4080739B2 - Application generating method for image forming apparatus and program causing computer to execute the method - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to an image forming apparatus application generation method and method for generating an application mounted on an image forming apparatus that provides a user service for image forming processing such as a copy, a printer, a scanner, and a facsimile, for verification of debugging work. The present invention relates to a program for causing a computer to execute.
[0002]
[Prior art]
2. Description of the Related Art In recent years, an image forming apparatus (hereinafter, referred to as “multifunction machine”) in which functions of apparatuses such as a printer, a copy machine, a facsimile machine, and a scanner are housed in a single housing is generally known. This multifunction device is provided with a display unit, a printing unit, an imaging unit, and the like in one casing, and is provided with three types of software respectively corresponding to a printer, a copying machine, and a facsimile machine. It operates as a copy, scanner or facsimile machine.
[0003]
In such a multi-function peripheral, image data is generated and output, so access to the memory frequently occurs. Therefore, it is important to verify whether or not the memory is normally accessed in the development stage of each software.
[0004]
As a conventional method for verifying such memory access, verification for verifying memory access at a location where an application program reads, writes, and allocates an operation in a source file of an application program. A method of embedding a code (tagging) and determining whether memory access is normal is generally known.
[0005]
[Problems to be solved by the invention]
However, in such a memory access verification method, when the source codes of all components are disclosed, it is verified whether or not the memory access is normal by embedding verification codes in all the locations where memory access is performed. However, if the source code of some components is not disclosed, it is not possible to verify a memory access failure that occurs inside a private component, and it is possible to perform accurate debugging work. There is a problem that you can not.
[0006]
For example, if a component for which a certain source code is disclosed provides only an object file for a standard function for character string manipulation and input / output as a C language standard library, and the source code for each function is not disclosed, such standard The memory access performed inside the function cannot be verified.
[0007]
Even if the source code of all components provided as a function library is released, if memory access is verified by excluding only a specific function library, a memory access error will occur inside the excluded function. If it is, accurate debugging cannot be performed.
[0008]
Here, in the case of a conventional multifunction device, application programs such as printer, copy, facsimile, and scanner are all developed by the producer of the multifunction device, and a third party such as a third vendor must develop a new application. Is not assumed, so the source code for all components is open to developers. Further, in the conventional multifunction peripheral, application programs that operate as processes in units of functions such as printers, copiers, facsimiles, scanners, etc. have been developed, and therefore, source codes such as standard functions of the C language standard library are not disclosed. Even when using, access to the memory is not complicated, and there is little trouble in debugging work.
[0009]
By the way, in such a conventional multi-function machine, software corresponding to a printer, a copy, a scanner, and a facsimile apparatus is provided separately, so that development of each software requires a lot of time. For this reason, the applicant has hardware resources used in image forming processing such as a display unit, a printing unit, and an imaging unit, and has an application that performs processing specific to each user service such as a printer, copy, or facsimile. When a user service is provided by interposing between these applications and hardware resources, hardware resource management, execution control, and image formation processing that are commonly required by at least two of the applications are provided. Invented an image forming apparatus (multifunction machine) equipped with a platform consisting of various control services.
[0010]
According to this multi-function peripheral, it is possible to improve the efficiency of software development by providing a platform for performing management, execution control, and image formation processing of hardware resources commonly required by at least two applications. As a result, the productivity of the entire apparatus can be improved.
[0011]
In such a new multifunction device, there are not only a plurality of application processes for each function, but also a control service process that provides services commonly required by at least two of the applications. As compared with the conventional multi-function machines, a great number of processes are executed in parallel while performing inter-process communication with each other. In addition, a plurality of threads are activated in each process, and a user service function is realized by performing inter-process communication with other processes while realizing parallel execution at the thread level. In other words, the novel multifunction peripheral invented by the applicant provides a user service for image forming processing such as copying, printers, scanners, facsimiles, etc., by cooperating in a complicated manner with many processes and threads. It is a typical composition.
[0012]
For this reason, in order to verify the operation of the multi-function device more accurately, it is necessary to perform the debugging work in a state where a large number of processes are operated cooperatively rather than performing the debugging work in units of processes. Since many processes are operating in such a multi-function peripheral, a shared memory that can be accessed in common by a plurality of processes is used, and the shared memory is accessed from many processes. Therefore, unlike the debugging work in the conventional multi-function peripheral, it becomes necessary to verify access to the shared memory from a large number of processes. For this reason, when using a function for which some source code is not disclosed, if a memory access error occurs inside the function, the impact on other processes is significant, compared to conventional multifunction devices. There is a problem that accurate debugging cannot be performed.
[0013]
Moreover, in such a new multifunction device, the application and the control service are provided separately, so after the multifunction device is shipped, a user or a third party as a third party develops a new application and installs it in the multifunction device. It is a configuration that is supposed to be. For this reason, when a newly developed application makes a function call using the function library provided to the control service, it is possible to verify whether the memory access is normally performed as the function is executed. It becomes necessary.
[0014]
However, since the control service is a module close to hardware resources, it is not desirable to disclose the processing procedure of each control service to a third party. Therefore, the control service source program may not be disclosed to a third party. Many. For this reason, the developer of a new application can embed the verification code for memory access in the source program of the application developed by himself, but cannot embed the verification code in the source program of the control service. A contradiction occurs in the memory access state, and there is a new problem that has not been a problem in the conventional multi-function peripheral development, in which the memory access cannot be accurately verified in the development of a new application.
[0015]
The present invention has been made in view of the above, and provides an image forming apparatus application generation method and method capable of accurately verifying memory access in development of an application that operates in an image forming apparatus in which a large number of processes operate. The object is to obtain a program to be executed by a computer.
[0016]
[Means for Solving the Problems]
  In order to achieve the above object, the invention according to claim 1A storage unit that stores an application for image information processing using hardware resources having a printing unit or an imaging unit, and a control unit that is defined as a service function that is called from the application and controls the hardware resource; , A processor, the processor reads the application and the control unit from the storage unit, and executes the read application and the control unit as processes, respectively. Perform inter-process communication with the process of the control unit by calling the service function and receiving the return value of the service function from the control unitImage forming apparatusofGenerate the application for verificationExecuted by the image forming device application generation deviceAn application generation method for an image forming apparatus,The application generating apparatus for the image forming apparatus is used for an application source file of the application including a description of the service function call, and an argument and a return value when the service function is called and the service function is called. A verification function source file in which the call process of the service verification function for executing the verification process for verifying the correctness of the state transition of the memory area, the verification process, and a return process for returning a return value are described; and an object of the service function A second storage unit that stores a service function library in which a file of a format is registered, and the function processing means is stored in the second storage unit beforeSource fileAnd read the app source fileThe service functionCall invocationTheDescription of the call to the service verification functionA function processing step to replace with,Code generation means reads the verification function source file stored in the second storage unit,The service verification function by the function processing stepCall invocationReplaced byThe appsource fileRead to the aboveVerification function source fileAre linked, and the object file generated by the compilation is linked with the service function library stored in the second storage unit.And a code generation step for generating the application.
[0017]
  According to the invention of claim 1,A function processing step of reading the source file stored in the second storage unit by a function processing step and replacing the description of the service function call in the read application source file with the description of the service verification function call And the code generation step reads the verification function source file stored in the second storage unit, and the function processing step reads the application source file replaced with the description of the service verification function call. The verification function source file is concatenated and compiled, and the executable application is generated by linking the object file generated by the compilation and the service function library stored in the second storage unit.Therefore, even if the source code of the service function is not disclosed, if you know the function of the service function, you can verify the memory status due to memory access by the service verification function when executing the application. Even when the source code is unknown, accurate debugging can be performed.
According to the first aspect of the present invention, the verification process for verifying the validity of the state transition of the memory area used for the argument and the return value when the service function is called by the service verification function is performed. Therefore, it is possible to grasp whether or not the memory allocation access is valid when the generated application is executed by the memory state transition. Therefore, it is possible to accurately detect a failure caused by the memory allocation access and perform more accurate debugging work. be able to.
[0018]
  The invention according to claim 2The input means isThe service function to be verifiedThe call description isSpecified setting informationAccept inputAn input step,
  The function processing step includes the stepThe appsource fileofThe service functionOf the call descriptionService function specified in the setting informationCall invocationThe service verification functionCall invocationIt is characterized by replacing with.
[0019]
  According to the invention of claim 2, the service function to be verified is input in the input step.The call description isSpecified setting informationAccept inputDepending on the function processing step,The appsource fileofThe service functionOf the call descriptionService function specified in the setting informationCall invocationThe service verification functionCall invocationBy substituting for the above, it is possible to verify the memory access in only a part of the functions, and to perform debugging work efficiently.
[0022]
  Claims3The invention according to,in frontThe service verification function isThe memory areaBy writing toSaidIt is characterized by verifying the state transition.
[0023]
  This claim3According to the invention, the service verification function by the service verification function is:The memory areaBy writing toSaidBy verifying the state transition, it is possible to grasp whether or not the memory write access is valid at the time of execution of the generated application, so it is possible to accurately detect the failure due to the memory write access. Accurate debugging can be performed.
[0024]
  Claims4The invention according to,in frontThe service verification function isThe memory areaBy reading againstSaidIt is characterized by verifying the state transition.
[0025]
  This claim4According to the invention, the service verification functionThe memory areaBy reading againstSaidBy verifying the state transition, it is possible to grasp whether or not the memory read access is valid at the time of execution of the generated application, so it is possible to accurately detect the failure due to the memory read access. Accurate debugging can be performed.
[0026]
  Claims5The invention according to,in frontThe service verification function isOf the memory areaBy openingSaidIt is characterized by verifying the state transition.
[0027]
  This claim5According to the invention, the service verification functionOf the memory areaBy openingSaidSince it is characterized by verifying the state transition, it is possible to grasp whether the memory free access is valid or not when executing the generated application, so it is possible to accurately detect a failure caused by the memory free access. More accurate debugging work.
[0028]
  Claims6The invention according toThe application source file further describes a standard function call that is a general-purpose function provided in advance in a programming language, and the second storage unit further includes the standard function call process and the standard function. The standard verification function call process, the verification process, and the return process for executing the verification process for verifying the correctness of the state transition of the memory area used for the argument and the return value at the time of calling and the return process for returning the return value A standard verification function source file in which processing is described, and a standard function library in which the object format file of the standard function is registered;The function processing step further includes theThe appsource fileOf the aboveStandard functionsCall invocationTheDescription of the standard verification function callIs replaced withThe code generation step further reads the standard function source file stored in the second storage unit,The standard verification function by the function processing stepCall invocationReplaced byThe appsource fileRead to the aboveVerification function source fileAre compiled, and the executable file is linked by linking the object file generated by the compilation and the standard function library stored in the second storage unit.The application is generated.
[0029]
  This claim6In accordance with the invention, the function processing step,further,SaidThe appsource fileOf the aboveStandard functionsCall invocationTheDescription of the standard verification function callIs replaced withThe code generation step further reads the standard function source file stored in the second storage unit,The standard verification function by the function processing stepCall invocationReplaced byThe appsource fileRead to the aboveVerification function source fileAre compiled, and the executable file is linked by linking the object file generated by the compilation and the standard function library stored in the second storage unit.By generating the application, even if memory access is performed not only from a service function but also from a standard function whose source code is not disclosed, if the function of the standard function is known, memory access is performed by the standard verification function when the application is executed. The memory state can be verified, and even if only a library of standard functions is provided, accurate debugging can be performed.
[0030]
  Claims7The invention according toThe second storage unit further stores a function table in which an argument at the time of calling the service function and an access method to the memory area are associated with each other, and a verification function code generation unit stores the function table from the second storage unit. With reference to the function table, based on the access method corresponding to the description of the service function call of the application source file, theGenerate service verification function source fileAnd store in the second storage unitVerification function code generation step,ThefurtherIt is characterized by including.
[0031]
  This claim7According to the invention concerningThe verification function code generation step refers to the function table from the second storage unit and generates the service verification function source file based on the access method corresponding to the description of the service function call in the application source file. And store in the second storage unitThus, even when the source code of the service function is not disclosed, it is not necessary for the debug operator to create the service verification function source file. For this reason, when the application is executed, the memory state by the memory access can be verified by the service verification function in which the source file is automatically generated, and accurate debugging work can be efficiently performed even when some source code is unknown. be able to.
[0034]
  Claims8The invention according to,in frontThe verification function code generation step, based on the processing content of the service function,The memory areaBy writing toSaidThe service verification function for verifying state transitionIncluding a description of the call toA service verification function source file is generated.
[0035]
  This claim8According to the invention, the verification function code generation step, based on the processing content of the service function,The memory areaBy writing toSaidThe service verification function for verifying state transitionIncluding a description of the call toBy generating a service verification function source file, when the application is executed, the service verification function that verifies the memory write access in which the source file was automatically generated, and whether or not the memory write access is valid is grasped by the memory state transition Therefore, it is possible to accurately detect a failure due to memory write access, and to perform more accurate debugging work efficiently.
[0036]
  Claims9The invention according to,in frontThe verification function code generation step, based on the processing content of the service function,The memory areaBy reading againstSaidThe service verification function for verifying state transitionIncluding a description of the call toA service verification function source file is generated.
[0037]
  This claim9According to the invention, the verification function code generation step, based on the processing content of the service function,The memory areaBy reading againstSaidThe service verification function for verifying state transitionIncluding a description of the call toBy generating a service verification function source file, when the application is executed, the service verification function that verifies the memory read access automatically generated by the source file is used to grasp whether the memory read access is valid or not by the memory state transition. Therefore, a failure due to memory read access can be detected accurately, and more accurate debugging work can be performed efficiently.
[0038]
  Claims10The invention according to,in frontThe verification function code generation step, based on the processing content of the service function,Release the memory areabySaidThe service verification function for verifying state transitionIncluding a description of the call toGenerate a service verification function source file.
[0039]
  This claim10According to the invention, the verification function code generation step, based on the processing content of the service function,Release the memory areabySaidThe service verification function for verifying state transitionIncluding a description of the call toBy generating a service verification function source file, when the application is executed, the service verification function that verifies the memory release access that automatically generated the source file, and whether or not the memory release access is valid is grasped by the memory state transition Therefore, it is possible to accurately detect a failure due to memory open access, and to perform more accurate debugging work efficiently.
[0042]
  Claims11The invention according to claim 1 to claim 110Since it is a program which makes a computer perform the method described in any one of Claim 1,10Any one of the operations can be executed by a computer.
[0043]
DETAILED DESCRIPTION OF THE INVENTION
Exemplary embodiments of an application forming method for an image forming apparatus and a program for causing a computer to execute the method according to the present invention will be explained below in detail with reference to the accompanying drawings.
[0044]
(Embodiment 1)
FIG. 1 is a block diagram showing a software configuration of a debugging device 100 according to the first embodiment of the present invention. The debugging apparatus 100 according to the first embodiment generates a new application that operates on an image forming apparatus (hereinafter referred to as “multifunction machine”) for debugging, loads the new application on the multifunction machine, and starts the application. This is to verify the memory access from the application. A debugging device 100 according to the first embodiment includes a compiler 110 with a debugging function and a linker 120 as shown in FIG.
[0045]
The compiler 110 with a debugging function uses a verification code (hereinafter referred to as a “tag”) or an overload described later according to a command specification for a source file 131 in which a source code of an application stored in the hard disk (HD) 130 is described. The tag function process is performed to generate an object file composed of the object code of the application. As shown in FIG. 1, the compiler 110 with a debugging function further includes a command analysis unit 111, a syntax analysis unit 112, an overload tag function processing unit 113, a tag addition unit 114, and a code generation unit 115. The Here, the overload tag function constitutes a service verification function and a standard verification function in the present invention.
[0046]
In the HD (hard disk) 130, a source file 131 in which the C language source code of the application is described, an overloaded tag function setting file 133 in an XML (eXtended Markup Language) format in which an overloaded tag function described later is specified, An overload tag function include file 134 in which an overload tag function declaration is described in C language source code and an overload tag function source file 135 in which processing of the overload tag function is described in C language source code are stored. . The HD 130 also includes an intermediate source file 138 in which service functions and standard functions are temporarily replaced with overload tag functions by the compiler 110 with a debugging function, and an object file generated from the source file 131 or the intermediate source file 138. 139 is generated, and an executable file 132 for debugging an application is generated by the linker 120.
[0047]
The overload tag function setting file 133 constitutes setting information in the present invention, and is created by the user. The overload tag function setting file 133 includes a specification of a function to be replaced with an overload tag function, a specification of an overload tag function include file name and an overload tag function source file, an overload tag function include file 134 and an overload. The storage destination directory of the tag function source file 135 is designated.
[0048]
The command analysis unit 111 of the compiler 110 with a debugging function analyzes parameters and syntax of a command input by a user using an input device such as a keyboard, and determines whether the input command is grammatically accurate. It is.
[0049]
The syntax analysis unit 112 receives the application source file 131 stored in the HD 130, analyzes the C language source code described in the source file 131 according to the C language grammar, and generates a derivation tree, a syntax tree, and the like. It performs the same processing as the syntax analysis in a normal compiler.
[0050]
The overload tag function processing unit 113 converts the control service function or C language standard function set as the debug target in the overload tag function setting file 133 from the functions described in the source file 131 to the corresponding overload. An intermediate source file 138 replaced with a tag function is generated. The tag adding unit 114 generates an intermediate source file 138 in which a tag that is a memory access verification code is added to the entrance and exit of a function described in the source file 131.
[0051]
When the overload tag function is specified by the overload tag function setting file 133, the code generation unit 115 converts the application intermediate source file 138 to which the tag is added by the tag addition unit 114 into the application object including the object code. A file 139 is generated. Further, the code generation unit 115 includes an intermediate source file 138 in which the service function and the standard function are replaced with the overload tag function by the overload tag function processing unit 113, an overload tag function include file 134, and an overload tag function source file. 135 is combined with one file to generate an object file 139 of an application consisting of an object code.
[0052]
The linker 120 links (links) the object file 139 generated by the code generation unit 115, the control service function library 136 and the standard function library 137 stored in the HD 130, and executes them on the OS of the multifunction machine and the computer. An executable format file 132 for debugging an executable application is generated.
[0053]
FIG. 2 is a block diagram of a hardware configuration of the debugging device 100 according to the first embodiment. As shown in FIG. 2, the debugging device 100 includes a control device 203 such as a CPU, a RAM (Random Access Memory) 205, an HD 130, a display device 202 such as a display device, and an input device 201 such as a keyboard and a mouse. And a communication device 204 such as a LAN board and a modem, and has a normal configuration using a computer such as a PC (Personal Computer) or a workstation. The debug device 100 is connected to an image forming apparatus (hereinafter referred to as “multifunction device”) 300 via a network such as a LAN 206, and the debug device 100 debugs the multifunction device 300 on the network. .
[0054]
Each part of the compiler 110 with a debugging function and the linker 120 are generated and executed on the RAM 205 when the debugging application generation program is executed. This debug application generation program is an executable or installable format on a storage medium such as a CD-ROM or FD as a part or all of a development tool kit such as a software development kit (SDK). Provided in a file. Also, such executable or installable format files may be provided in a manner that can be obtained via a network.
[0055]
Next, the MFP 300 that is the debug target will be described. FIG. 3 is a block diagram illustrating a functional configuration of the multifunction machine 300. As shown in FIG. 3, the multi-function apparatus 300 includes a monochrome line printer (B & W LP) 301, a color line printer (Color LP) 302, hardware resources such as a scanner, a facsimile, a hard disk (HD), a memory, and a network interface. And a software group 310 including a platform 320 and an application 330.
[0056]
The platform 320 interprets a processing request from the application 330 and generates a hardware resource acquisition request, and a system resource that manages one or a plurality of hardware resources and arbitrates the acquisition request from the control service. A manager (SRM) 323 and a general-purpose OS 321 are provided.
[0057]
The control service is formed by a plurality of service modules, and includes an SCS (system control service) 322, an ECS (engine control service) 324, an MCS (memory control service) 325, an OCS (operation panel control service) 326, and an FCS. (Fax control service) 327 and NCS (network control service) 328. The platform 320 has an application programming interface (API) that can receive a processing request from the application 330 using a predefined function.
[0058]
The general-purpose OS 321 is a general-purpose operating system such as UNIX (registered trademark), and executes each software of the platform 320 and the application 330 in parallel as processes.
[0059]
The process of the SRM 323 performs system control and resource management together with the SCS 322. The SRM323 process uses the hardware resources of the scanner, printer, and other engines, memory, HDD files, and host I / O (centro I / F, network I / F, IEEE 1394 I / F, RS232C I / F, etc.). Arbitration is performed according to the request from the upper layer to be used, and execution control is performed.
[0060]
Specifically, the SRM 323 determines whether the requested hardware resource is available (whether it is not used by another request), and if it is available, the requested hardware resource is used. Tell the upper layer that it is possible. In addition, the SRM 323 performs hardware resource usage scheduling in response to a request from an upper layer, and directly executes the request contents (for example, paper conveyance and image forming operation, memory allocation, file generation, etc. by the printer engine). .
[0061]
The process of the SCS 322 performs application management, operation unit control, system screen display, LED display, resource management, interrupt application control, and the like.
[0062]
The ECS 324 process controls the engine of a hardware resource 303 including a monochrome line printer (B & W LP) 301, a color line printer (Color LP) 302, a scanner, a facsimile, and the like.
[0063]
The MCS 325 process acquires and releases image memory, uses a hard disk drive (HDD), compresses and decompresses image data, and the like.
[0064]
The FCS327 process performs facsimile transmission / reception using the PSTN / ISDN network from each application layer of the system controller, registration / quotation of various facsimile data managed by BKM (backup SRAM), facsimile reading, facsimile reception printing, and fusion transmission / reception. Provides an API to do.
[0065]
The NCS 328 process is a process for providing a service that can be commonly used for applications requiring network I / O. Data received from the network side according to each protocol is distributed to each application, and data from the application Mediation when sending to the network side. Specifically, it has server daemons such as ftpd, httpd, lpd, snmpd, telnetd, and smtpd and client functions of the same protocol.
[0066]
The OCS 326 controls an operation panel (operation panel) serving as information transmission means between the operator (user) and the main body control. The OCS 326 acquires a key press from the operation panel as a key event, sends a key event function corresponding to the acquired key to the SCS 322, and displays various screens on the operation panel according to a request from the application 330 or the control service. A drawing function for drawing output, a function for controlling the operation panel, and the like are composed of pre-registered OCS library portions. The OCS library is implemented by being linked to each module of the application 330 and the control service. The OCS 326 may be configured to operate as a process, or the OCS 326 may be configured as an OCS library.
[0067]
The application 330 includes a printer application 311 that is a printer application having a page description language (PDL), PCL, and PostScript (PS), a copy application 312 that is a copy application, and a fax application 313 that is a facsimile application. , A scanner application 314 that is a scanner application, a network file application 315 that is a network file application, and a process inspection application 316 that is a process inspection application. Each of these applications 330 is generated and operated as a process by an initialization unit (not shown) when the MFP 300 is activated.
[0068]
Each process of the application 330 and each process of the control service realize a user service related to image forming processing such as copying, printer, scanner, facsimile, etc. while performing inter-process communication by calling a function, sending its return value, and sending / receiving a message. is doing.
[0069]
As described above, the MFP 300 according to the first embodiment includes a plurality of applications 330 and a plurality of control services, all of which operate as processes. In each of these processes, one or a plurality of threads are generated and parallel execution is performed in units of threads. The control service provides a common service to the application 330. For this reason, a large number of these processes perform a parallel operation and a parallel operation of threads to perform inter-process communication with each other. User services related to image forming processing such as copying, printers, scanners, and facsimiles are provided.
[0070]
In addition, a third party such as a third vendor can develop and install a new application (new application 317) in the application layer above the control service layer in the MFP 300. The debugging device 100 according to the first embodiment performs a debugging operation in order to verify memory access at the development stage of the new application 317.
[0071]
FIG. 4 is a block diagram showing the relationship between the new application 317 and the control service function call. That is, the process between the processes of the new application 317 and the control service process (ECS 324 in FIG. 4) using the API (application programming interface) and the function provided by the control service (ecs_func function in FIG. 4). When communication is performed, the function called on the control service side is executed.
[0072]
At this time, it is determined whether or not the state transition of the memory area due to the memory access is normal when the area is secured to the memory, the memory is read / written, or the memory is released along with the execution of the function. It has become. In such a case, it is possible to verify the memory access by adding a tag, which is a memory access verification code, to the location where the memory access of the new application 317 and the control service is performed without using the overload tag function. . However, in the MFP 300 according to the first embodiment, the function provided by the control service is provided only by an object code called a function library, and the source code of each provided function is not disclosed to a third party. Therefore, the memory access cannot be verified by this, and therefore the memory access is verified using the overload tag function.
[0073]
Next, a method for generating a new application for debugging and a memory access verification method using the debugging device 100 and the debugging application generation program according to the first embodiment configured as described above will be described. FIG. 5 is an explanatory diagram showing the files used and generated and the overall flow of the new debug application in the process of generating the new debug application.
[0074]
A user who debugs a new application inputs the next command at the command prompt% from the input device 201 such as a keyboard of the debugging device 100 in order to generate an execution format file of the new application for debugging.
[0075]
% Dbgcc source file name -o executable file name
Here, “dbgcc” is the designation of startup of the compiler with a debugging function and the linker, “source file name” is the source file name of the new application, and “−o executable file name” is the executable file name of the new application. Indicates. In addition, when nothing is set in the environment variable OVR_XML at the time of executing such a command, processing for adding a tag that is a memory access verification code to the entry and exit of the function in the source file of the new application is performed. An executable file is generated.
[0076]
On the other hand, when an overload tag function setting file name is set in the environment variable OVR_XML, an executable file that can perform memory access verification using the overload tag function is generated. For example, in the example of FIG. 5, the following environment variable setting and command input will start generation processing of a new application executable file using the overload tag function.
[0077]
Environment variable OVR_XML = "newappl.xml"
% Dbgcc newappl. c-o newappl. exe
[0078]
In the example of FIG. 5, when the new application 317 performs inter-process communication with the ECS process as a control service, the function ecs_jobmode () provided by the ECS 324 is called, and the memory access memory state performed in the ecs_jobmode () And a new application for debugging that verifies the memory state of the memory access performed in the standard function strcppy (). Here, the ECS function library 136 (ecs.lib) in which ecs_jobmode () is registered and the standard function library 137 (standard.lib) in which strcpy () is registered are both provided to the user as object files. Therefore, the source code of ecs_jobmode () and strcpy () is not disclosed, and it is impossible to tag the source code of such a function. For this reason, in the example of FIG. 5, the memory access verification is made possible by using the overload tag function.
[0079]
In the overload tag function setting file 133 (newappl.xml), the overload tag function include file 134 (ecs_ovrlfunc.h) and the overload tag function source file 135 (ecs_ovrlfunc.c) are replaced with the overload tag function. The functions ecs_jobmode and strcppy are specified.
[0080]
FIG. 6 is an explanatory diagram showing the contents of the overload tag function setting file 133 in the example of FIG. The overload tag function setting file 133 is created by the user before the start of debugging work.
[0081]
As shown in FIG. 5, the directory path of the overload tag function include file 134 and the overload tag function source file 135 is specified in the attribute “path” of the tag <dbgcc>. The attribute “source” of the tag <incfile> has the file name (ecs_ovrlfunc.c) of the overload tag function source file 135, and the attribute “include” has the file name of the overload tag function include file 134 (ecs_ovrlfunc.h). ) Is specified. A tag <func> specifies a function name to be replaced with an overload tag function, that is, a function name for performing memory access verification. In the examples of FIGS. 5 and 6, “ecs_jobmode” and “strcpy” are specified in the tag <func>, respectively.
[0082]
FIG. 7 is a flowchart illustrating a procedure for generating a new debug application. In the following, each file in FIG. 5 will be described as an example. When the user sets the overload tag function setting file 133 (newappl.xml) in the environment variable OVR_XML and starts the command dbgcc with the new application source file (newappl.c) as an argument, the compiler 110 with a debug function is first started. Is started and the command input by the command analysis unit 111 is analyzed (step S701). Specifically, parameters and syntax are analyzed to determine whether the input command is grammatically correct.
[0083]
Next, the syntax analysis unit 112 reads the new application source file 131 (newappl.c) (step S702), and performs syntax analysis of the C language source code described in the source file 131 (step S703). Specifically, the syntax analysis unit 112 analyzes the C language source code according to the C language grammar, and generates a derivation tree, a syntax tree, and the like.
[0084]
Then, the command analyzer 111 checks the setting contents of the environment variable OVR_XML (step S704). If nothing is set in the environment variable OVR_XML, the overload tag function is not processed and a tag is added as a memory access verification code to the function entry and exit of the source file 131 (step S706). The object code of the new application is generated from the tagged source file 131 and stored in the HD 130 as the object file 139 (step S707).
[0085]
On the other hand, if the file name (newappl.xml) of the overload tag function setting file 133 is set in the environment variable OVR_XML in step S704, the overload tag function processing unit 113 performs overload tag function processing and code generation. The code generation processing by the unit 115 is performed to generate an object code for the new application, and the object file 139 is stored in the HD 130 (step S705).
[0086]
Then, the object file 139 described in the generated object code of the new application 317, the ECS function library 136, and the standard function library 137 are linked to generate the execution format file 132 of the new application for debugging 317 ( Step S708).
[0087]
Next, the overload tag function process and the code generation process performed in step S705 described above will be described. FIG. 8 is a flowchart showing the procedure of overload tag function processing and code generation processing.
[0088]
First, the overload tag function processing unit 113 reads the overload tag function setting file 133 (newappl.xml) set in the environment variable OVR_XML (step S801). Then, the overload tag function processing unit 113 refers to the <func> tag of the overload tag function setting file 133 (newappl.xml) and lists all the functions to be replaced with the overload tag function (step S802). Then, an intermediate source file 138 is generated in the HD 130, and the contents of the source file 131 (newappl.c) are copied to the intermediate source file 138 (step S803).
[0089]
Next, the overload tag function processing unit 113, as shown in FIG. 5, in the intermediate source file 138 copied from the source file 131 (newappl.c), the function name “ecs_jobmode” specified by the <func> tag. ”Is replaced with the overload tag function“ ecs_jobmode_ ”(step S804). The overload tag function name is determined by adding “_” to the function name described in the source file 131 as shown in FIG. 5, but the overload tag function corresponding to each function is defined. The name of the overload tag function can be arbitrarily determined.
[0090]
At the time of replacement, the first argument and the second argument of the overload tag function ecs_jobmode_ are added, and the argument of the original function ecs_jobmode is described after the third argument. Here, the first argument of the overload tag function specifies the source file name (newappl.c) for displaying the verification result, and the second argument is the number of lines of the replaced function in the source file 131. This is also specified for displaying the verification result.
[0091]
Such replacement of the function with the overload tag function is repeated for all the functions listed in step S802 (step S805). As a result, as shown in FIG. 5, the standard function strcppy is also replaced with the overload tag function strcppy_, and the ECS service function ecs_msgalloc is replaced with the overload tag function ecs_msgalloc_.
[0092]
Next, the code generation unit 115 causes the directory path of the overload tag function include file 134 and the overload tag function source file 135 from the attribute “path” of the <dbgcc> tag of the overload tag function setting file 133 (newappl.xml). Are obtained from the attribute “include” of the <incfile> tag, and the overload tag function include file 134 (ecs_ovrlfunc.h) is inserted at the beginning of the intermediate source file 138 (step S806). . Also, the code generation unit 115 acquires the overload tag function source file name from the attribute “source” of the <incfile> tag, and inserts the overload tag function source file 135 (ecs_ovrlfunc.c) after the intermediate source file 138. (Step S807).
[0093]
Then, the code generation unit 115 converts the source code of the intermediate source file 138 into which the overload tag function include file 134 and the overload tag function source file 135 are inserted into object code in the same processing procedure as that of a normal compiler. Then, the object file 139 (newappl.o) of the new application for debugging is generated (step S808). The object file 139 is linked to the ECS function library 136 (ecs.lib) and the standard function library 137 (standard.lib) by the linker 120 as described in step S708 of FIG. A file 132 (newappl.exe) is generated.
[0094]
Next, the overload tag function source file 135 will be described in detail. In the debugging device 100 according to the first embodiment, the overload tag function source file 135 needs to be created in advance by the user before executing the dbgcc command. FIG. 9 is an explanatory diagram showing an example of details of the overload tag function source file 135. FIG. 9 shows details of the memory access tracking process in the overload tag function source file 135 shown in FIG.
[0095]
In the overload tag function, first, the replacement source function is executed, and then a memory tracking process for checking the state transition of the memory is executed according to the processing contents of the memory access of the function.
[0096]
Here, the state transition of the memory area will be described. FIG. 10 is an explanatory diagram showing the relationship between memory state transition and memory access. In FIG. 10, the initial state is a state in which no area is secured or initialized in the memory, and memory securing access is possible for the memory in the initial state, but an error occurs if other accesses are made. It becomes. The secured state is a state in which an area is secured in the memory but has not been initialized yet. The memory in the reserved state can be released or accessed for writing, but an error occurs if another access is made. The written state is a state where an area is secured in the memory and initialized. Although write access, read access, and open access are possible for a memory in a write state, an error occurs if another access is performed.
[0097]
Further, the state transition of the memory is as follows. As shown in FIG. 10, when a secure access is made to the memory in the initial state, the memory is in a secured state. Further, when a write access is made to the secured memory, the memory is in a write state. When read access or write access is made to the memory in the write state, the memory remains in the write state. When open access is made to a memory in a reserved state or a written state, the memory is in an initial state. The debugging application generation program executed by the debugging device 100 according to the first embodiment includes the following memory state event function for checking the state transition of the memory in order to check the state transition. Here, the first argument addr is the start address of the memory area to be inspected, and the second argument indicates the size of the memory area to be inspected.
[0098]
(1) event_alloc (char * addr, int size)
A memory allocation event is generated in an area in the range from the memory address addr to size bytes, and it is checked whether the memory state transition is normal. When the memory state transitions from the initial state to the secured state, a normal return value is returned. Otherwise, an abnormal return value is returned. The return value of the abnormality is a return value that varies depending on the state of the transition source.
[0099]
(2) event_read (char * addr, int size)
A memory read event is generated in an area in the range from the memory address addr to size bytes, and it is checked whether or not the memory state transition is normal. A normal return value is returned when the memory state transitions from the write state to the write state, and an abnormal return value is returned otherwise. The return value of the abnormality is a return value that varies depending on the state of the transition source.
[0100]
(3) event_write (char * addr, int size)
A memory write event is generated in an area ranging from the memory address addr to size bytes, and it is checked whether the memory state transition is normal. When the memory state transitions from the writing state to the writing state, or when the memory state transitions from the secured state to the writing state, a normal return value is returned. Otherwise, an abnormal return value is returned. The return value of the abnormality is a return value that varies depending on the state of the transition source.
[0101]
(4) event_free (char * addr, int size)
A memory release event is generated in an area in the range from the memory address addr to size bytes, and it is checked whether or not the memory state transition is normal. When the memory state transitions from the secured state to the initial state, or when the memory state transitions from the write state to the initial state, a normal return value is returned. Otherwise, an abnormal return value is returned. The return value of the abnormality is a return value that varies depending on the state of the transition source.
[0102]
Each memory state event function obtains the memory state before and after the transition by issuing an OS system call that obtains the current state of the memory and the state before the transition to the region in the above range. . In the example of the overload tag function in FIG. 9, the replacement source ecs_jobmode function performs the process of reading the contents of the memory area pointed to by the pointers para1 and para2 of the argument, and then processes the process with the process ID specified by pid. It is an ECS service function that performs job mode setting processing. Therefore, in the overload tag function ecs_jobmode_ corresponding to the ecs_jobmode function, as shown in FIG. 9, first, after executing the replacement source ecs_jobmode function, the memory state event of event_read is performed for each memory area pointed to by para1 and pointer para2 A function is issued to check the state transition of each memory area.
[0103]
The replacement source strcppy function is a standard function that copies the contents of the area pointed to by the argument pointer src to the area indicated by the argument dest pointer. For this reason, in the overload tag function strcppy_ corresponding to the strcppy function, as shown in FIG. 9, first, after executing the replacement source strcppy function, the memory state event function of event_read is issued to the memory area pointed to by src. The memory state event function of event_write is issued to the memory area pointed to by dest to check the state transition of each memory area.
[0104]
Also, the replacement source ecs_msgalloc function is an ECS service function that secures the area pointed to by the argument pointer msg_area as a message area. For this reason, in the overload tag function ecs_msgalloc_ corresponding to the ecs_msgalloc function, as shown in FIG. 9, first, after executing the replacement source ecs_msgalloc function, the memory state event function of event_alloc is issued to the memory area pointed to by msg_area. Checking the state transition of the memory area.
[0105]
Therefore, when the execution format file 132 of the new application 317 for debugging is executed, the state transition of the memory is checked by the above-described overload tag function, and an error is displayed if it is abnormal. It is possible to verify the memory access of only a part of the functions without causing any contradiction.
[0106]
The memory area indicated by the argument pointer of each function is a memory area secured outside the function. By using such an overload tag function, in addition to the memory area accessed inside the function, It is possible to verify the memory access even for the memory area accessed outside the function in distinction from the internal memory area.
[0107]
As described above, in the debugging device 100 and the debugging application generation program according to the first embodiment, the overload tag function processing unit 113 replaces the control service function of the new application source file 131 with the overload tag function, and generates code. The unit 115 generates a new application debug execution format file 132 from the new application source file 131 replaced with the overload tag function, the overload tag function include file 134, and the overload tag function source file 135. Since the execution format file 132 for debugging is executed, the memory state transition by the memory access is verified even when the source code of the control service function or the standard function is not disclosed. Door can be, it is possible to perform accurate debugging.
[0108]
In the debugging device 100 and the debug application generation program according to the first embodiment, since the memory access verification is performed using the overload tag function, only the function necessary for the debugging work is replaced with the overload tag function. For this reason, it is possible to verify the memory access for only a part or a specific function in the new application 317, and to perform debugging work efficiently.
[0109]
In addition, memory access can be verified by replacing only a specific function with an overload tag function in this way, so that memory access outside the function and memory access inside the function can be distinguished, or depending on the CPU or compiler. The memory access can be verified by distinguishing the place and the independent place, and the debugging work can be performed more efficiently.
[0110]
The contents of each file described in the first embodiment are merely examples, and the contents are not particularly limited.
[0111]
(Embodiment 2)
The debugging device 100 and the debugging application generation program according to the first embodiment have been verified after the overload tag function include file 134 and the overload tag function source file 135 are created in advance by the user. The debug device 1100 and the debug application generation program according to the second form automatically generate the overload tag function include file 134 and the overload tag function source file 135 when compiling the source file of the new application, and An executable file is generated.
[0112]
FIG. 11 is a block diagram of a software configuration of the debugging device 1100 according to the second embodiment. A debugging device 1100 according to the second embodiment includes a compiler 1110 with a debugging function and a linker 120 as shown in FIG.
[0113]
The compiler 1110 with a debug function performs tag and overload tag function processing on the source file 131 in which the source code of the application stored in the hard disk (HD) 130 is described according to the designation of the command, and from the object code of the application. An object file is generated. As shown in FIG. 11, the compiler with debug function 1110 further includes a command analysis unit 111, a syntax analysis unit 112, an overload tag function code generation unit 1111, an overload tag function processing unit 113, and a tag addition unit 114. And a code generation unit 115.
[0114]
The compiler 1110 with a debug function according to the second embodiment is different from the compiler 110 with a debug function in the first embodiment in that an overload tag function code generation unit 1111 is provided. This is the same as the compiler 110 with a debugging function.
[0115]
The overload tag function code generation unit 1111 generates an overload tag function corresponding to the function specified in the overload tag function setting file 133 set by the user, and describes the declaration of each generated overload tag function The overload tag function include file 134 and the overload tag function source file 135 describing the processing of each overload tag function are generated in the HD 130.
[0116]
Similar to the debugging device 100 according to the first embodiment, the HD (hard disk) 130 stores a source file 131 and an overload tag function setting file 133. In the debugging apparatus 1100 according to the second embodiment, the debug execution format file 132, the intermediate source file 138, and the object file 139 are generated in the HD 130 during the generation process of the new debug application 317. Unlike the apparatus 100, the overload tag function include file 134 and the overload tag function source file 135 are also generated by the compiler 1110 with a debug function. The structure and contents of each file are the same as the file structure and contents described in the first embodiment.
[0117]
Next, a method for generating a new debugging application 317 and a memory access verification method using the debugging apparatus 1100 according to the second embodiment configured as described above and the debugging application generation program will be described. Regarding the command analysis processing by the command analysis unit 111, the syntax analysis processing of the source file 131 by the syntax analysis unit 112, and the link processing between the object file 139 and each library by the linker 120, the debugging apparatus 100 according to the first embodiment shown in FIG. This is the same as the processing procedure in the debug application generation program.
[0118]
FIG. 12 is a flowchart showing a procedure of overload tag function code generation processing, overload tag function processing, and code generation processing. First, the overload tag function processing unit 113 reads the overload tag function setting file 133 (newappl.xml) set in the environment variable OVR_XML (step S1201). Then, the overload tag function processing unit 113 refers to the <func> tag of the overload tag function setting file 133 (newappl.xml) and lists all the functions to be replaced with the overload tag function (step S1202).
[0119]
Next, the overload tag function code generation unit 1111 determines an overload tag function name corresponding to the listed function name, and an overload tag function include file 134 in which the declaration of each overload tag function is described. The load tag function source file 135 is generated and stored in the directory path specified by the overload tag function setting file 133 with the file name specified by the file 133 (step S1203).
[0120]
Here, generation processing of the overload tag function source file 135 by the overload tag function code generation unit 1111 will be described. As described in the first embodiment, the overload tag function appropriately selects a memory state event function according to the access method for the memory of the replacement source function, and verifies the state transition caused by the memory access. In other words, in the process of the function, when the read access is made to the memory area pointed to by the argument pointer, the memory transition state is checked by the event function of event_read after the function is executed, and the memory area pointed to by the argument pointer is stored. When write access is performed, the transition state of the memory is checked by an event function of event_write after the function is executed. Therefore, in the debugging device 1100 according to the second embodiment, an access method for the area indicated by the argument of a function that can be replaced with an overload tag function is held in advance in the function table.
[0121]
FIG. 13 is an explanatory diagram showing an example of such a function table. FIG. 13 records the access method to the memory area pointed to by each argument pointer for each of the functions ecs_jobmode, ecs_msgalloc, and strcppy that are the replacement source of the overload tag function shown in FIG. The overload tag function code generation unit 1111 refers to the function table for each function argument, determines read access, write access, reserved access, and release access, and determines the memory status event functions event_read, event_write, event_alloc, and event_free. The overload tag function source file 135 is generated by selecting from among them. Further, the overload tag function code generation unit 1111 describes the declaration of the generated overload tag function and generates the overload tag function include file 134.
[0122]
When the overload tag function include file 134 and the overload tag function source file 135 are generated in step S1203 of FIG. 12, an intermediate source file 138 is generated on the HD 130, and the contents of the source file 131 (newappl.c) are transferred to the intermediate source. Copy to file 138 (step S1204). Subsequent replacement of the target function with the overload tag function by the overload tag function processing unit 113, conversion to an object code by the code generation unit 115, and generation processing of the object file 139 (steps S1205 to S1209) are as follows. This is performed in the same manner as the procedure (steps S804 to S808) described with reference to FIG. 8 by the debug device 100 and the debug application generation program of the first embodiment. The generated object file 139 is linked with the ECS function library 136 (ecs.lib) and the standard function library 137 (standard.lib) by the linker 120, whereby the executable file 132 (newappl.lib) of the new application 317 for debugging is linked. exe) is generated.
[0123]
As described above, in the debug device 1100 and the debug application generation program according to the second embodiment, the overload tag function code generation unit 1111 uses the overload tag function source file 135 of the overload tag function for the control service function and the standard function. Since the overload tag function include file 134 is automatically generated, it is not necessary for the debug operator to create the overload tag function source file 135 and the overload tag function include file 134, and accurate debugging work can be efficiently performed. Can be done.
[0124]
In the debugging apparatus 1100 and the debugging application generation program according to the first and second embodiments, the case of generating a new application has been described. However, the present invention can also be applied to generation of other control services. is there.
[0125]
【The invention's effect】
  As described above, according to the first aspect of the present invention, even when the source code of the service function is not disclosed, if the function of the service function is known, the memory access is performed by the service verification function when the application is executed. The memory state can be verified, and even when some source code is unknown, an accurate debugging operation can be performed.In addition, according to the first aspect of the present invention, it is possible to accurately detect a failure due to memory allocation access, and to perform more accurate debugging work.
[0126]
Further, according to the invention of claim 2, it is possible to verify memory access in only a part of functions, and there is an effect that debugging work can be performed efficiently.
[0128]
  Claims3According to the present invention, it is possible to accurately detect a failure caused by memory write access and to perform more accurate debugging work.
[0129]
  Claims4According to the invention, it is possible to accurately detect a failure due to memory read access and to perform more accurate debugging work.
[0130]
  Claims5According to the invention, it is possible to accurately detect a failure caused by memory open access and to perform more accurate debugging work.
[0131]
  Claims6According to the present invention, even when performing memory access not only from a service function but also from a standard function whose source code is not disclosed, as long as the function of the standard function is known, the standard verification function can be The memory state can be verified, and even when only a standard function library is provided, an accurate debugging operation can be performed.
[0132]
  Claims7According to the present invention, even when the source code of the service function is not disclosed, the debugging operation can be efficiently performed without creating the service verification function source file by the debugging worker himself / herself. Play.
[0134]
  Claims8According to the present invention, when an application is executed, a failure due to memory write access can be accurately detected by a service verification function for verifying memory write access in which a source file is automatically generated, thereby enabling more accurate debugging work efficiently. The effect that it can be performed automatically is produced.
[0135]
  Claims9According to the present invention, when an application is executed, a failure caused by memory read access can be accurately detected by a service verification function for verifying memory read access in which a source file is automatically generated. The effect that it can be performed automatically is produced.
[0136]
  Claims10According to the present invention, when an application is executed, a failure due to memory free access can be accurately detected by a service verification function for verifying memory free access in which a source file is automatically generated. The effect that it can be performed automatically is produced.
[0138]
  Claims11According to the invention according to claim 1,10There is an effect that any one of the operations can be executed by a computer.
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating a functional configuration of a debugging device according to a first embodiment;
FIG. 2 is a block diagram of a hardware configuration of the debugging device according to the first embodiment;
FIG. 3 is a block diagram illustrating a functional configuration of the multifunction peripheral according to the first embodiment;
FIG. 4 is a block diagram illustrating a relationship between a new application of the multifunction peripheral according to the first embodiment and a function call of a control service.
FIG. 5 is an explanatory diagram illustrating a file used and generated and a whole flow of the new debug application in the generation process of the new debug application in the debugging device according to the first embodiment;
6 is an explanatory diagram showing an example of the contents of an overload tag function setting file in FIG. 5 in the debugging device according to the first embodiment; FIG.
FIG. 7 is a flowchart of a process for generating a new debug application in the debugging device according to the first embodiment;
FIG. 8 is a flowchart showing a procedure of overload tag function processing and code generation processing in the debugging apparatus according to the first embodiment;
FIG. 9 is an explanatory diagram illustrating an example of details of an overload tag function source file in the debugging device according to the first embodiment;
FIG. 10 is an explanatory diagram illustrating a relationship between memory state transition and memory access in the multifunction peripheral according to the first embodiment;
FIG. 11 is a block diagram of a functional configuration of the debugging device according to the second embodiment;
FIG. 12 is a flowchart showing a procedure of overload tag function code generation processing, overload tag function processing, and code generation processing in the debugging apparatus according to the second embodiment;
FIG. 13 is an explanatory diagram of an example of a function table used in the debugging device according to the second embodiment;
[Explanation of symbols]
100,1100 Debugging device
110,1110 compiler
111 Command analyzer
112 Parsing section
113 Overload tag function processor
114 Tag adder
115 Code generator
120 linker
130 Hard disk (HD)
131 New application source file
132 Executable file for debugging
133 Overload tag function setting file
134 Overload tag function include file
135 Overload tag function source file
136 Control Service Function Library
137 Standard Function Library
138 Intermediate source file
139 Object file
201 Input device
202 display device
203 Controller
204 Communication device
205 RAM
300 MFP
301 Monochrome line printer
302 color line printer
303 Hardware resources
310 Software group
311 Printer app
312 Copy application
313 Fax application
314 Scanner application
315 Net file application
316 Process inspection app
317 New App
320 platform
321 General-purpose OS
322 SCS
323 SRM
324 ECS
325 MCS
326 OCS
327 FCS
328 NCS
330 applications
1111 Overload tag function code generator

Claims (11)

A storage unit that stores an application for image information processing using hardware resources having a printing unit or an imaging unit, and a control unit that is defined as a service function that is called from the application and controls the hardware resource; , A processor, the processor reads the application and the control unit from the storage unit, and executes the read application and the control unit as processes, respectively. image forming apparatus to generate the application of the control of the process and an image forming apparatus for performing inter-process communication by the call from the control unit performs performing the reception of the return value of the service function of the service functions for verification Execute on application generator An image forming apparatus for application generation method,
The application generating apparatus for the image forming apparatus is used for an application source file of the application including a description of the service function call, and an argument and a return value when the service function is called and the service function is called. A verification function source file in which the call process of the service verification function for executing the verification process for verifying the validity of the state transition of the memory area, the verification process, and a return process for returning a return value are described; A second storage unit for storing a service function library in which a file of a format is registered,
Function processing means, said second reading out the previous SL source file storage unit stored in the read calls description of the service functions of the application source files, functions to replace the call of description of the service verification function Processing steps;
Code generating means, said stored in the second storage unit reads the verification function source file, the verification function read the call the application source files substituted in the description of the service verification function by the function processing step A code generation step of linking and compiling source files , and generating the application in an executable format by linking the object file generated by compilation and the service function library stored in the second storage unit ;
A method for generating an application for an image forming apparatus, comprising: The input means further includes an input step of receiving input of setting information in which a description of calling the service function to be verified is specified,
The function processing step, from the invocation of description of the service functions of the application source files, calls to description of the service function specified in the setting information, to replace the call of description of the service verification function The image forming apparatus application generation method according to claim 1, wherein the image forming apparatus application generation method is an image forming apparatus application generation method. The service verification function, the image forming device application generating method according to claim 1 or 2, characterized in that verifying the state transition by writing to the memory area. The service verification function, the image forming device application generating method according to any one of claims 1-3 which by reading the memory areas, characterized in that verifying the state transition. The service verification function, the memory area claim 1 for image forming apparatus application generation method according to any one of 4, characterized in that verifying the state transition by the opening of. The application source file further describes a call to a standard function that is a general-purpose function provided in advance in a programming language.
The second storage unit further returns a verification process and a return value for verifying the validity of the state transition of the memory area used for the argument and return value when the standard function is called and the standard function is called. A standard verification function source file in which the calling process of the standard verification function for executing the return process, the verification process, and the return process are described; and a standard function library in which an object format file of the standard function is registered. ,
The function processing step further replaces the description of the standard function call in the application source file with the description of the standard verification function call ,
Wherein the code generating step further reads the standard functions source file stored in the second storage unit, read the application source files substituted with descriptions of invocations of the standard validation function by the function processing step The verification function source file is connected and compiled, and the executable application is generated by linking the object file generated by the compilation and the standard function library stored in the second storage unit. the image forming device application generating method according to any one of claims 1-5, characterized. The second storage unit further stores a function table in which an argument at the time of calling the service function is associated with an access method for the memory area,
The verification function code generation means refers to the function table from the second storage unit, and determines the service verification function source file based on the access method corresponding to the description of the service function call in the application source file. Generating a verification function code to be generated and stored in the second storage unit ;
The application generating method for an image forming apparatus according to claim 1 , further comprising: The verification function code generating step, based on the processing content of the service function, to generate the service verification function source file containing a call of description of the service verification function for verifying the state transition by writing to the memory area The image forming apparatus application generation method according to claim 7 . The verification function code generating step, based on the processing content of the service function, to generate the service verification function source file containing a call of description of the service verification function for verifying the state transition by reading to the memory area 9. The method for generating an application for an image forming apparatus according to claim 7 or 8 . The verification function code generating step, based on the processing content of the service function, to generate the service verification function source file containing a call of description of the service verification function for verifying the state transition due to the opening of the memory area 10. The method for generating an application for an image forming apparatus according to any one of claims 7 to 9 . The program which makes a computer perform the method as described in any one of Claims 1-10 .

Images