JP3503504B2 - Debug processing system, computer and debug processing method - Google Patents

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a debugging technique for a program operating on a computer (electronic computer), and in particular, a plurality of operating systems (OS) operating in different memory spaces on a single computer. program including an OS that operates in a multi-OS environment for operating Te (hereinafter, described as "multi-memory space program") suitable for debugging a debug processing system
The present invention relates to computer and debug processing method and.

[0002]

2. Description of the Related Art In developing a program for an electronic computer, a debug device, that is, a debugger is used to investigate the order of operation of a program and the malfunction of the program in order to develop a program that operates correctly. This debugger is provided with a function of stopping execution of a specified instruction in a program instruction, a function of reading and writing a value in a memory, and the like. This makes it possible to check whether or not the program operates correctly. Note that the technology related to such a debugger is Jonathan.
B. Rosenberg, Kunio Yoshikawa, “How Debuggers Work Debugger Theory and Implementation” (1998, published by ASCII Corporation)
It is described in.

In an electronic computer environment, there is provided a system that constitutes a multi-OS environment in which a plurality of OSs are operated in cooperation with one electronic computer. A technique related to a program debugging support technique in such a multi-OS system is disclosed in, for example, Japanese Patent Laid-Open No. 10-1339.
There is a technique described in JP-A-10. This is a general-purpose OS that is the development environment for application programs (application programs) and real-time OS that is the execution environment for application programs.
In the multi-OS system in which S operates on the same electronic computer, the cooperative operation of the application program to be debugged and the application program to be debugged is realized. Here, the cooperative operation is an operation in which a plurality of programs communicate with each other to execute one process.

The debugger used in Japanese Patent Laid-Open No. 10-133910 utilizes an emulator device provided by the multi-OS system. However, it is characterized by having no emulator device, each OS having an independent memory space, scheduling the execution of the OS according to an interrupt processing procedure, and operating a plurality of OSs simultaneously by one computer. No debugger is provided for a multi-OS system having a memory space. In the case of a multi-OS system having such a multi-memory space, the conventional debugging technique develops and operates a debugger corresponding to each OS.

That is, when a plurality of programs are operating in a multi-memory space, a debugger for each memory space is used to debug each program (multi-memory space program) including the OS operating in each memory space. Must be activated. Further, when each multi-memory space program operates in cooperation with each other, if debugging is performed for each program in each memory space, debugging related to the cooperation operation will be insufficient.

[0006]

The problem to be solved is that, in the conventional technique, a program (multi-memory space program) operating simultaneously in the multi-memory space cannot be debugged by one debugger. The point is that it is not possible to debug corresponding to the cooperative operation of programs in the multi-memory space.

An object of the present invention is to solve these problems of the prior art and to operate in a multi-OS environment in which a plurality of operating systems (OS) operate in conjunction with each other in different memory spaces on one computer. Lud bagged system and the computer and debugging to enable to perform debug space program efficiently
It is to provide a processing method.

[0008]

To achieve the above object, according to an aspect of, debug processing system and the computer and de Bas <br/> Tsu grayed processing method of the present invention, the exception handler to be used for debugging, multi-memory Shared in a program that operates in space. This allows the exception to be caught in any memory space. When an exception is caught in a space different from the space where the debug device is installed, the shared exception handler performs space switching to the space where the debug device is installed and then causes a breakpoint exception again. This makes it possible to catch an exception in another space in the space where the debug device is mounted.

In order to share and manage the exception handler, a common memory area in which a program in each memory space can be operated is provided, and setting information and an interrupt table of each memory space are set in this common memory area. Register the information of the shared exception handler (shared handler) in the interrupt table. Then, the shared handler switches from each memory space to the memory space in which the debugger operates by using the setting information of the memory space. The exception handler used for debugging is valid regardless of privilege level,
It can be captured regardless of the privilege level of each program.

In addition, information necessary for debugging a program in each memory space, such as a table for managing breakpoints, is set in the common memory area, and a debugger operating in a certain memory space can debug this common memory area. By manipulating the information, it becomes possible to debug the program in each memory space.

Further, in the case of configuring a multi-OS environment, when a general-purpose OS exists as one OS, it is possible to reduce the development man-hours of the debugger by effectively using the abundant debuggers of the general-purpose OS. Then, by using only this debugger to debug the program including the OS in the other memory space, the debug environment can be shared and the convenience is enhanced. For example, it can be effectively used for OS development that operates in a memory space different from the memory space in which the debugger operates.

[0012]

BEST MODE FOR CARRYING OUT THE INVENTION Embodiments of the present invention will be described in detail below with reference to the drawings. FIG. 1 is a block diagram showing a configuration example of a debugging system according to the present invention. This Figure 1
In FIG. 1, 100 is a debug target computer in which a program to be debugged is operating, and 110 is a debugger computer activated by a debugger for debugging the program on the debug target computer 100.

The debug target computer 100 is composed of a processor (described as "CPU" in the figure) 101, a memory 102, a bus 107, and a communication device 108. In the memory 102, in order to operate a plurality of programs without affecting each other, each program reserves a dedicated memory area. That is, a memory area is secured so that one program cannot use the memory area of the other program.

In this example, two memory spaces having the above properties are secured. Each area of this memory
The first memory space 104 and the second memory space 105 are used.
Further, the common memory area 103 is secured in consideration of the mutual operation of the programs. In the common memory area 103, an interrupt table, space setting information of each memory space, break point information, and the like are secured, the details of which will be described later.

An input device 112 such as a keyboard and an output device 113 such as a CRT (Cathode Ray Tube) are connected to the debugger computer 110. This debugger computer 1
A debugger (described as “a debugger targeting the first memory space” in the figure) 111 provided in the unit 10 is a debugger that debugs a program in the first memory space 104 in the debug target computer 100. The operation of the debugger 111 is performed by the input device 112, and the debug result is output by the output device 113.

The debug computer 110 is connected to the debug target computer 100 by a cable 109, and the debugger 11
The instruction for debugging No. 1 from the communication device 114 passes through the cable 109, the communication device 108 of the debug target computer 100, and the bus 107, and the first memory space 10
Debugging support program 10 mapped to 4
Pass to 6.

The debug support program 106 receives an instruction from the debugger 111 and sets a debug instruction for the program to be debugged. The debugger 111
In addition to control of breakpoints and control of single step execution, it is possible to reference and write to physical memory from memory reference and writing with virtual addressing.

As described above, since the debugger 111 can refer to and write to the physical memory, the common memory area 103
Space information (the space information table 21 shown in FIG.
0) is used to analyze the paging situation, and the mapping situation of the physical memory can be referred to and written from the virtual address of the program in the second memory space 105. As a result, the code of the breakpoint instruction of the program in the second memory space 105 can be set by the debugger 111 operating in the first memory space 104.

FIG. 2 is an explanatory diagram showing a configuration example of the common memory area in FIG. In the common memory area 103,
Spatial information table 210, interrupt table 220,
Breakpoint table 230, register table 2
40, trace table 250, operation space flag (indicated as “operation space (first and second)” in the figure) 260, debug mode flag (in the figure, “debug mode (On or Of
f) ”), single-step execution stop mode flag (described as“ single-step execution stop mode (On or Off) ”in the figure) 280, trace execution mode flag (“ trace execution mode (On or Off) in the figure ”) Off) "
281 and a single step execution determination flag (in the figure, "single step execution determination (On or Of
f) ”) 282 is provided.

In the common memory area 103, the programs in the first memory space 104 shown in FIG.
It is also available from the 5 programs. Therefore, the operation of the debugger can be controlled by the states of the tables (210 to 250) and the flags (260 to 282) in the common memory area 103. As a result, the breakpoint exception handler and the exception handler that occurs at the time of single step execution can be used separately for normal use and for debugging by specifying a flag. That is, it is not necessary to separately set an exception handler for debugging and an exception handler normally used at system startup.

The spatial information table 210 is shown in FIG.
The address of the page table in the first memory space 104 and the second memory space 105 is stored as the page table position 211, and the address of the stack used in each space is stored as the stack pointer position 212. Can identify each memory space.

The interrupt table 220 stores a base address 221 of each handler and an interrupt handler setting (indicated as "interrupt setting" in the drawing) 222 for each interrupt exception handler identifier. Thus, the interrupt table 220 is placed in the common memory area 103,
Shared by interrupt exception handlers in each memory space.

The breakpoint table 230 has a second
A breakpoint address 231 for registering an address where a breakpoint is set in the memory space 105, and an instruction code before the breakpoint is set, that is,
An original code 232 for registering an original instruction code, and an area for registering whether a breakpoint in a table is valid or invalid (described as "valid or invalid" in the figure) 23
It is composed of three. When setting a breakpoint, the breakpoint can be controlled by setting each item in the table in the breakpoint table 230.

In the register table 240, the register name and its value are stored in the respective item fields of the register name 241 and the value 242, and in the trace table 250, the trace data is stored in the item of the trace data 251. The operation space flag 260 indicates whether the operation space is the first or second memory space, the debug mode flag 270 indicates whether the operation space is the debug mode or the normal mode, and the single step execution stop mode is set. The flag 280 indicates whether or not the single-step execution stop mode is set, the trace execution mode flag 281 indicates whether or not the trace execution mode is set, and the single-step execution determination flag 282 indicates that When debugging with the example technique, it indicates whether the debug exception handler issued a breakpoint.

The operation of the debug system in FIG. 1 using such a table and flags will be described below. FIG. 3 is a flowchart showing a first processing procedure example of the debugging method according to the present invention of the debugging system in FIG. This example shows an example of a processing procedure for a breakpoint exception. When a breakpoint is issued in each memory space, the interrupt table 220 of FIG.
The breakpoint exception handler registered in (starts as "shared handler") is started.

The shared handler started up is first. It is determined whether the program is operating in the first memory space 104 (step 301). The first memory space 104 is a memory space in which the debugger 111 is operating, and its determination is made by the value of the operation space flag 260 in FIG.

If operating in the first memory space 104,
The process moves to the breakpoint exception handler of the first memory space 104 (step 302). That is, the debugger 1
The breakpoint exception handler used by the debug support program 106 for 11 is used.

When operating in a region other than the first memory space 104 (here, the second memory space 105), the contents of the register are saved (step 303 in order to return to the state before the interrupt later). ), And determine if this handler is being used for debugging (step 304). This determination is made based on the value of the debug mode flag 270 in FIG. If not in debug mode
The program in the second memory space 105 shifts to the breakpoint exception handler normally used (step 30).
6).

When operating in the debug mode, it is further determined whether or not the breakpoint is issued by the debug exception handler (step 305). This is because when debugging with the technique of this example, the debug exception handler may issue a breakpoint, as will be described later with reference to FIG. 4, and the determination here is set by the debug exception handler. The single step execution determination flag 282 of FIG. That is, if the single step execution determination flag 282 is set, it is determined as a breakpoint issued from the debug exception handler.

As described above, if the breakpoint is issued from the debug exception handler, the process proceeds to step 309. That is, since the breakpoint code from the debug exception handler is incorporated from the beginning, it is not necessary to manipulate the instruction pointer at the breakpoint issue position. Also, saving the contents of the register during execution of the debug exception handler does not provide valid information. Therefore, in this case, the processing of the next steps 307 and 308 is not necessary.

If the process is not for the breakpoint issued from the debug exception handler in step 305, the instruction pointer is changed to the breakpoint issue position (step 307). When the interrupt handler returns to program operation, the instruction pointer is typically set to return to the address following the address where the interrupt occurred. However, in order to return to the code of a normal program, it is necessary to return the code for breakpoints to the original code before registering the breakpoint, return to the position of the breakpoint code, and execute from that original code. is there. The process of returning to the original code is performed in step 314 described later.

Next, the contents of the registers saved in step 303 are transferred to the register table 24 in the common memory area 103.
Write to 0 (step 308). The debugger 111
Since the common memory area 103 can be referred to by the virtual address designation, the value of the register at the time of issuing the breakpoint can be referred to by designating the symbol or address of the table. Next, the spatial information of the second memory space 105 is stored in the spatial information table 210 (step 30).
9).

Further, the memory space is switched from the second memory space 105 to the first memory space 104 (step 3).
10). Information for switching the memory space to the first memory space 104 is acquired and set from the space information table 210 of FIG. 2, and the operation space flag of FIG. 2 is changed to the first memory space. Then, a breakpoint is issued (step 311). As a result, the shared handler is executed again, this time in step 301, the first memory space 1
It is regarded as the breakpoint of 04, and the processing moves to the breakpoint exception handler of the first memory space 104.

As described above, the operation of the shared handler causes the debugger 1 to operate on the first memory space 104.
11 can catch a breakpoint in the second memory space 105. If the debugger 111 can stop the operation at the break point, the program in the second memory space 105 can also stop at the time of issuing the break point in step 311. That is, by setting a breakpoint in the second memory space 105, the debugger 111 targeting the first memory space 104 can capture the breakpoint in the second memory space 105.

When the breakpoint exception handler issued in the first memory space 104 ends, the second
The space is switched again to the memory space 105 (step 3)
12). This is done in the process of step 309 based on the space information of the second memory space stored in the space information table 210 of FIG. 2, and the operation space flag of FIG. 2 is changed to the second memory space. As a result, again, the second memory space 1
On 05, the shared handler will run.

Then, it is again determined whether or not the breakpoint is issued by the debug exception handler (step 313). The single step execution determination flag 282 of FIG. 2 is also used for the determination here. That is,
If the single step execution determination flag 282 is set, it is determined as a breakpoint issued from the debug exception handler. In the case of the breakpoint issued by the debug exception handler in this way, the breakpoint code of the debug exception handler is incorporated from the beginning, so that it is not necessary to perform steps 314 to 316, and the process proceeds to step 317. .

If it is not the breakpoint issued by the debug exception handler, the original code is written at the address designated as the breakpoint (step 314). This is done by taking out the original code of the address at which the breakpoint occurred from the breakpoint table 230 of FIG. This will cause the shared handler to
From the address you set the breakpoint, the original code will work.

Further, it is judged whether the designation of the break point is valid (step 315). This is done by checking the address of the breakpoint that caused the shared handler from the breakpoint address 231 in the breakpoint table 230 of FIG. 2 and judging by the state of the item 233 corresponding to the address indicating whether the breakpoint is valid or invalid. If it is valid, the process proceeds to step 316, and if it is invalid, the process proceeds to step 317.

At step 316, the single step execution mode is set, and then the operation is shifted to step 317. The processing operation in this single step execution mode is necessary when repeatedly using the specification of the breakpoint. That is, the rewritten breakpoint code is written again in the breakpoint code by the exception handler called at the time of single step execution. Details of the exception handler called during such single step execution will be described later with reference to FIG.

In step 317, the contents of the register saved in the process of step 303 are restored. Then, this shared handler is terminated. Due to the processing procedure of the shared handler as described above, another memory space (second
A program breakpoint in the memory space 105) can be captured.

FIG. 4 is a flowchart showing a second processing procedure example of the debugging method according to the present invention of the debugging system in FIG. This example shows an example of the processing procedure for a debug exception that is called during single step execution.

When a debug exception occurs, it is determined whether the first memory space 104 is operating (step 40).
1). The first memory space 104 is a memory space in which the debugger 111 is operating. Further, the determination is made based on the value of the operation space flag 260 shown in FIG.

If it is operating in the first memory space 104, the process moves to the debug exception handler for the first memory space (step 402). In addition, the first memory space 104
If it is operating in other than the above, first, the contents of the register are saved in case of returning to the state before the interruption later (step 403). Next, it is determined whether this exception handler is used for debugging (step 404). This determination is made based on the value of the debug mode flag 270 in FIG.

If it is not in the debug mode, the program in the second memory space 105 shifts to the debug exception handler normally used (step 405). When the debug mode is activated, it is first determined whether or not a break point instruction has been written at the position of the break point to be valid (step 406). This determination is made based on whether or not the address at which the single step execution has occurred and the breakpoint address 231 of the breakpoint table 230 of FIG. 2 are equal.

If there is an address determined here, a breakpoint instruction is written at that address position (step 407). In this way, by re-enabling the breakpoint, the state at the time of setting the breakpoint is maintained and the state of setting the breakpoint is continued.

Next, it is determined whether or not the single step execution is canceled (step 408). This is the single step execution stop mode flag 280 and the trace execution mode flag 281 of the common memory area 103 in FIG.
It judges by the value of. Here, the single step execution stop mode is a mode used to stop the operation and debug each time the single step execution is performed.

If neither flag is specified,
The single step execution is canceled (step 409).
This is achieved by changing the processor settings. In this way, by canceling single-step execution, after this exception handler ends, the normal execution status is the same as when the breakpoint was set, and then the registers are restored (step 410) and the debug exception handler ends. To do.

If the single step execution is not canceled in the process of step 408, step 4
The contents of the register saved in the processing of 03 are written in the register table 240 of FIG. 2 (step 411).
Since the debugger 111 can refer to the common memory area 103 by virtual address designation, it can refer to the register value at the time of single step execution by designating the symbol or address of the table.

Then, it is judged whether the single step execution stop mode is designated (step 41).
2). This is determined by whether the single step execution stop mode flag 280 of FIG. 2 is designated. This processing is to stop after each single step execution and to see the state with a debugger, or to perform only trace and determine whether to execute without stopping after each single step execution.

If the single step execution stop mode is designated, the single step execution determination flag 2 in FIG.
82 is set (step 413). Then, a breakpoint is issued to stop at each single step execution (step 414). The breakpoint issued here is different from the processing of the breakpoint set by the debugger 111, so step 41
The single step execution determination flag is set so that the break pointer exception handler (shared handler) that performs the processing of FIG. 3 can determine that it is the breakpoint issued in 4.

By issuing a breakpoint in step 414, it is possible to stop at a breakpoint after each single step execution, and the shared handler can capture a breakpoint other than the memory space in which the debugger is operating. It is possible to refer to the single-step executed state of the second memory space 105 by the debugger 111 operating in the first memory space 104.

After that, the setting of the single step execution determination flag 282 is canceled (step 415). And
Next, it is judged whether or not the trace execution mode is designated (step 416). If the trace execution mode has been designated, the process proceeds to step 417.

In this step 417, the trace data is transferred to the trace table 25 of the shared area 103 in FIG.
Save to 0. This enables the debugger 111 to refer to the trace data. Further, it can be referred from the program in the first memory space 104. After the process of step 417, or if the trace execution mode is not designated in step 416, the process proceeds to step 418.

At step 418, it is determined whether the single step execution mode is to be ended. This is determined by the values of the single step execution mode flag 280 and the trace execution mode flag 281 shown in FIG. That is,
If neither flag is specified, the single step execution is terminated, and the process proceeds to step 409. Also, if either flag is set,
Single step execution shall be continued, and step 41
The processing shifts to 0.

The exception handler for performing the processing described with reference to FIGS. 3 and 4 is common to the programs in the multi-memory space, and an exception is generated in the breakpoint and the single step execution regardless of the difference in the memory space. Can be captured for each. Therefore, even in a multi-OS environment in which a plurality of programs each having a different virtual memory space operate cooperatively, it is possible to debug a program in the multi-memory space according to the order of the cooperative operation.

Further, in debugging a program in a multi-memory space, by setting each memory space information of the space information table and setting the break point table 230 for each memory space (104, 105), the memory space is increased or decreased. Can be easily dealt with.

As described above with reference to FIGS. 1 to 4, in the debug system and the debugging method for a multi-memory space program of this example, an exception handler (shared handler) called when a breakpoint exception occurs and a single step execution. An exception handler (debug exception handler) that is sometimes called is shared by programs in each memory space.

Then, even in a program in the second memory space different from the first memory space in which the debugger operates, the exception handler (shared handler) of the breakpoint exception issued by the program in the second memory space is the debugger. The debugger captures the breakpoint of the program in the different memory space by switching the space to the working memory space of and issuing the breakpoint again.

As a result, it is possible to debug a plurality of programs (multi-memory space programs) including the OS that operate simultaneously in the multi-memory space with a single debugger, and it is possible to cooperate with the multi-memory space programs. And the breakpoints can be continuously set. For example, the debugging technique of this example can be effectively used for developing an OS that operates in the second memory space. .

Also, according to this example, when single step execution is set for each multi-memory space program, the exception handler at the time of single step execution issues a breakpoint and calls the shared handler. Thus, regardless of which memory space each program is, the debugger operating in the first memory space can capture the single step execution.

Further, according to this example, when single step execution is set for each multi-memory space program, the exception handler at the time of single step execution stores the trace data in the common memory area. , It is possible to refer to the trace data of each program in one memory space.

Further, in this example, the data status of the program different from the memory space in which the debugger operates can be written in the common memory area accessible from each memory space to capture the data required for debugging. It is possible. As a result, the state of the register at the time of issuing the breakpoint can be stored in the common memory area and can be referenced by the debugger or application.

Further, in this example, by preparing a flag set by the exception handler for debugging in the common memory area, the processing of the exception handler can be changed according to the value of the flag. As a result, it is possible to distinguish between the exception handler used during debugging and the exception handler processing normally used without changing the code of the exception handler.

The present invention is not limited to the embodiments described with reference to FIGS. 1 to 4, and various modifications can be made without departing from the scope of the invention. For example, in this example, as shown in FIG.
The debug target computer 100 is configured to be debugged via the communication devices 114 and 108. However, this is done even when the debug target computer 100 is down due to a failure in the OS of the debug target computer 100.
The information is obtained, and if there is no such risk, the debugger 111 may be executed on the debug target computer 100.

[0065]

According to the present invention, it is possible to debug a program including an OS (multi-memory space program) that simultaneously operates in the multi-memory space with a single debugger, and to perform a cooperative operation of the multi-memory space program. Multi-OS that can be debugged correspondingly and operates multiple operating systems (OS) in conjunction with each other in different memory spaces on one computer
It is possible to efficiently debug a multi-memory space program operating in the environment.

[Brief description of drawings]

FIG. 1 is a block diagram showing a configuration example of a debug system according to the present invention.

FIG. 2 is an explanatory diagram showing a configuration example of a common memory area in FIG.

FIG. 3 is a flow chart showing a first processing procedure example of a debugging method according to the present invention of the debugging system in FIG.

FIG. 4 is a flowchart showing a second processing procedure example of the debugging method of the debugging system in FIG. 1 according to the present invention.

[Explanation of symbols]

100: computer to be debugged, 101: processor, 1
02: memory, 103: common memory area, 104: first
Memory space, 105: second memory space, 106: debug support program, 107: bus, 108: communication device,
109: cable, 110: debugger computer, 111:
Debugger (debugger for the first memory space), 1
12: input device, 113: output device, 114: communication device, 210: spatial information table, 211: page table position, 212: stack pointer position, 220: interrupt table, 221: base address, 222: interrupt handler setting ( Interrupt setting), 230: Breakpoint table, 231: Breakpoint address, 232: Original code, 233: Area (valid or invalid),
240: register table, 241: register name, 24
2: value, 250: trace table, 251: trace data, 260: operation space flag (operation space (first and second)), 270: debug mode flag (debug mode (On or Off)), 280: single step Execution stop mode flag (Single step execution stop mode (On
282: trace execution mode flag (trace execution mode (On or Off)), 282: single step execution determination flag (single step execution determination (On or Off)).

Front page continuation (72) Inventor Tomoki Sekiguchi 1099 Ozenji, Aso-ku, Kawasaki-shi, Kanagawa Hitachi Systems Development Laboratory, Ltd. Development Laboratory (72) Inventor Risa Tomita 1 Ikegami, Haruoka-cho, Owariasahi-shi, Aichi Hitachi Information Technology Division (56) (JP, A) (58) Fields surveyed (Int.Cl. ⁷ , DB name) G06F 9/46-9/54 G06F 11/28-11/34

Claims (9)

(57) [Claims] 1. A multiple operating system (O
S) storing a plurality of programs each performing the operation
Debug and computer having a memory space, a debugging processing <br/> stem having a debugger computer to perform the process of debugging the program, the computer, by the debugger computer among the plurality of OS
Stores the program that operates the first OS that can be processed
A first memory space, the first memory space of the plurality of memory spaces divided
Storing Ku and second memory space, the configuration information of the plurality of memory spaces each said double
Connected to a common memory area that can be shared by several OSs, the first memory space, and the second memory space
And the plurality of memos stored in the common memory area.
Control that performs space switching control according to the setting information of each space
And a control unit, the control unit of the computer, the breakpoint exception the second
If it occurs in the memory space of
According to the stored setting information of each of the plurality of memory spaces
The operation space of the above program to the second memory space
Switch to the first memory space from above, and the debugger computer sets the breakpoint exception in the first memory space.
Issued characterized to Lud bag processing system to. 2. The debug processing system according to claim 1 , wherein a tray is stored in the common memory area during single step execution.
To Lud bus and characterized in that we have a means for storing Sudeta <br/> Tsu grayed processing system. 3. Either claim 1 or claim 2.
The debug processing system described in 1 above , which is necessary for debugging each program stored in each memory space.
Transfer necessary data from each memory space to the common memory area
To Lud bagged and characterized in that it have a means for writing sheet
Stem. 4. A plurality of operating systems (O
S) storing a plurality of programs each performing the operation
A computer having a memory space, of a first OS capable of debug processing among the plurality of OSs
A first memory space for storing a program for performing an operation and the first memory space among the plurality of memory spaces are excluded.
The second memory space and the setting information of each of the plurality of memory spaces are stored, and
Connected to a common memory area that can be shared by several OSs, the first memory space, and the second memory space
And the plurality of memos stored in the common memory area.
When space switching control is performed according to the setting information for each space
Both have a control system for performing debug processing in the first memory space.
And a control unit, in which the breakpoint exception is the second memory.
If it occurs in the space, the operation space of the program above
Switch from the second memory space to the first memory space
Therefore, in the first memory space, the above breakpoint exception
Issuing a calculator . 5. The computer according to claim 4 , wherein a tray is stored in the common memory area during single step execution.
Calculation having means for storing data
Machine . 6. Either claim 4 or claim 5 .
A computer according to either 必debugging of the programs stored in the memory space
Transfer necessary data from each memory space to the common memory area
A computer having means for writing . 7. A plurality of operating systems (O
S) storing a plurality of programs each performing the operation
It met debugging method of the program in a computer having a memory space, the computer, the breakpoint exception, among the plurality of OS debugging
Stores the program that operates the first OS that can be processed
Occurs in the second memory space excluding the first memory space
Common memory area that can be shared by multiple OSs
According to the setting information of each of the plurality of memory spaces stored in
Then, the operation space of the program is set to the second memory.
Space to the first memory space and switch to the first memory space.
In the memory space, wherein to Lud bag processing method to issue the breakpoint exception. De bag processing method der according to 8. The method of claim 7
And Tsu, when sheet packaging le stepping tray to the common memory area
Features and to Lud bagged how <br/> method to store Sudeta. 9. Either claim 7 or claim 8.
It met debugging processing method according to either 必debugging of the programs stored in the memory space
The main data, <br/> writing write-law, features and be Lud bag processing method to the common memory area from the memory space.