JP2000181748A - Debug system for multi-memory space program and its debug method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To debug a program containing OS operating on a multi-memory space with a debugger corresponding to one memory space. SOLUTION: The processing of a brake point exception shared by the programs of multi-memory spaces 104 and 105 by placing a brake point exception handler in a common memory area 103. If the brake point of the program in the prescribed memory space differs from the first memory space 104 where a debugger 111 starts when it is acquired, the space is switched to the first memory space 104 and the brake point is issued again. Thus, the brake point of the second memory space 105 can be acquired by the debugger 111. The single step execution of the other memory space can be acquired by the debugger 111 by calling the common handler at the time of executing a single step.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a technique for debugging a program operating on a computer (electronic computer), and more particularly, to linking a plurality of operating systems (OS) in different memory spaces on a single computer. The present invention relates to a debugging system and a debugging method for a multi-memory space program suitable for debugging a program including an OS operating in a multi-OS environment (hereinafter, referred to as a “multi-memory space program”).

[0002]

2. Description of the Related Art In developing a computer program, a debugging device, that is, a debugger, is used to investigate the order of operation of the programs and the malfunctions of the programs in order to develop programs that operate correctly. The 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 the program operates correctly. The technology related to such a debugger is described in Jonathan
B. Rosenberg, Translated by Kunio Yoshikawa, "Theory and Implementation of How Debuggers Work Debugger" (ASCII, 1998)
It is described in.

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

The debugger used in Japanese Patent Application Laid-Open No. 10-133910 uses an emulator device provided by a multi-OS system. However, there is no emulator device, each OS has an independent memory space, the execution of the OS is scheduled by an interrupt processing procedure, and a plurality of OSs are operated simultaneously by one computer. No debugger is provided for multi-OS systems with memory space. In the case of a multi-OS system having such a multi-memory space, in the conventional debugging technique, a debugger corresponding to each OS is developed and operated.

That is, when a plurality of programs are operating in a multi-memory space, to debug each program (multi-memory space program) including an OS operating in each memory space, a debugger must be provided for each memory space. Must be started. Further, when the multi-memory space programs operate in cooperation with each other, if the debugging is performed for each program in each memory space, the debugging related to the cooperative operation is insufficient.

[0006]

The problems to be solved are that, in the prior art, a program (a multi-memory space program) operating simultaneously in a multi-memory space cannot be debugged by one debugger. The point is that debugging cannot be performed in accordance with the cooperative operation of programs in a multi-memory space.

SUMMARY OF THE INVENTION An object of the present invention is to solve these problems of the prior art, and to provide a multi-memory operating in a multi-OS environment in which a plurality of operating systems (OS) are operated in conjunction in different memory spaces on a single computer. An object of the present invention is to provide a debugging system and a debugging method for a multi-memory space program, which enable efficient debugging of a space program.

[0008]

To achieve the above object, the present invention provides a system and a method for debugging a multi-memory space program, wherein an exception handler used at the time of debugging is shared among programs operating in a multi-memory space. I do. This allows the exception to be caught in any memory space. Then, when an exception is caught in a space different from the space in which the debug device is mounted, the shared exception handler switches the space to the space in which the debug device is mounted, and then raises a breakpoint exception again. As a result, an exception in another space can be caught 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 for 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 using the setting information of the memory space. Exception handlers used for debugging are valid regardless of privilege level,
Capture is possible regardless of the privilege level of each program.

Further, 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 is used for debugging the common memory area. By manipulating the information, it becomes possible to debug the program in each memory space.

In the case of configuring a multi-OS environment, when a general-purpose OS is provided as one OS, a debugger with a wide variety of general-purpose OSs can be effectively used, thereby reducing the development man-hour of the debugger. Then, by using only this debugger to debug a program including an OS in another memory space, a debug environment can be shared and convenience is improved. For example, it can be effectively used for developing an OS that operates in a memory space different from the memory space in which the debugger operates.

[0012]

Embodiments of the present invention will be described below in detail with reference to the drawings. FIG. 1 is a block diagram showing an embodiment of a configuration according to the present invention of a debugging system for a multi-memory space program of the present invention. In FIG. 1, reference numeral 100 denotes a computer to be debugged on which a program for debugging is operating, and 110 denotes a computer 1 to be debugged.
00 is a debugger computer that is activated by a debugger that debugs the program on 00.

The computer 100 to be debugged includes a processor (described as “CPU” in the figure) 101, a memory 102, a bus 107, and a communication device 108. In the memory 102, each program secures a dedicated memory area so that a plurality of programs operate without affecting each other. That is, a memory area is secured so that one program cannot use the memory area of the other program.

In this embodiment, two memory spaces having the above properties are secured. This area of memory is
A first memory space 104 and a second memory space 105 are provided.
In addition, the common memory area 103 is reserved in consideration of the mutual operation of the programs. Although details will be described later, the common memory area 103 secures an interrupt table, space setting information of each memory space, breakpoint information, and the like.

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 calculator 1
A debugger 111 (described as “a debugger targeting the first memory space” in the figure) 111 provided in 10 is a debugger that debugs a program in the first memory space 104 in the computer 100 to be debugged. The operation of the debugger 111 is performed by the input device 112, and the result of debugging is output by the output device 113.

The debug computer 110 is connected to the debug target computer 100 by a cable 109, and
1 from the communication device 114 via the cable 109 via the communication device 108 and the bus 107 of the computer 100 to be debugged.
Debug 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 debug target program. The debugger 111
In addition to control of breakpoints and control of single-step execution, it is possible to refer to and write to physical memory from memory reference and write at virtual address designation.

As described above, the debugger 111 can refer to and write to the physical memory.
(The spatial information table 21 shown in FIG. 2 below)
The paging situation is analyzed by using (0), 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. Thus, the code of the breakpoint instruction of the program in the second memory space 105 can be set from 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,
A spatial information table 210, an interrupt table 220,
Breakpoint table 230, register table 2
40, a trace table 250, an operation space flag (described as “operation space (first, second)” 260), a debug mode flag (“debug mode (On or Of)
f) ”) 270, 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) "
281) and a single-step execution determination flag (“Single-step execution determination (On or Of
f) ") 282 is provided.

The common memory area 103 is stored in the second memory space 10 from the program in the first memory space 104 shown in FIG.
5 programs are also available. 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 during single-step execution can be used for normal use and for debug depending on the flag specification. In other words, there is no need to separately set a debug-only exception handler and a normally used exception handler at system startup.

In the spatial information table 210, FIG.
The address of the page table in the first memory space 104 and the address of the page table in the second memory space 105 are stored as a page table position 211, and the address of a stack used in each space is stored as a stack pointer position 212. Thus, each memory space can be identified.

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

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

In the register table 240, the register name and its value are stored in the respective item columns of the register name 241 and the value 242. 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 mode is the debug mode or the normal mode, and the single step execution stop mode. 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 sets When debugging with the example technique, it indicates whether the debug exception handler has 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 a processing procedure example for a breakpoint exception. When a breakpoint is issued in each memory space, the interrupt table 220 in FIG.
A breakpoint exception handler (hereinafter, referred to as a "shared handler") registered in the program starts.

First, the activated shared handler starts. It is determined whether a 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 operates, and its determination is made based on the value of the operation space flag 260 in FIG.

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

When operating outside 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 interruption later. ), It is determined whether or not this handler is 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 shifts to a breakpoint exception handler normally used by the program in the second memory space 105 (step 30).
6).

When operating in the debug mode, it is further determined whether or not the breakpoint is issued by a debug exception handler (step 305). This is because the debug exception handler may issue a breakpoint as described later with reference to FIG. 4 when debugging with the technique of the present example, and the determination here is set by the debug exception handler. The single step execution determination flag 282 shown in 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 has been issued from the debug exception handler, the flow shifts to step 309. That is, since the code of the breakpoint from the debug exception handler is incorporated from the beginning, there is no need to manipulate the instruction pointer at the breakpoint issue position. Also, even if the contents of the register during execution of the debug exception handler are saved, the information is not valid. Therefore, in this case, the processing of the following steps 307 and 308 is not necessary.

If it is determined in step 305 that the processing is not for the breakpoint issued from the debug exception handler, 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 normal program code, it is necessary to return the breakpoint code to the original code before registering the breakpoint, return to the breakpoint code position, and execute from the original code is there. The process of returning to the original code is performed in step 314 described later.

Next, the contents of the register stored in step 303 are stored in the register table 24 of the common memory area 103.
Write 0 (step 308). The debugger 111
Since the common memory area 103 can be referred to by specifying a virtual address, the value of the register at the time of issuing a breakpoint can be referred to by specifying a table symbol or address. Next, the space information of the second memory space 105 is stored in the space 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). The information for switching the memory space to the first memory space 104 is obtained 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.
It is regarded as a breakpoint of the first memory space 104, and the process proceeds to a breakpoint exception handler of the first memory space 104.

As described above, by operating the shared handler, the debugger 1 operating on the first memory space 104
11 can catch a breakpoint in the second memory space 105. If the operation of the debugger 111 can be stopped by a breakpoint, the program in the second memory space 105 can also be stopped at the time of issuing the breakpoint in step 311. That is, if a breakpoint in the second memory space 105 is set, 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 performed in 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
05, the shared handler will operate.

Thereafter, it is determined again whether or not the breakpoint has been issued by the debug exception handler (step 313). The single step execution determination flag 282 in FIG. 2 is 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. If the breakpoint is issued by the debug exception handler as described above, the code of the breakpoint of the debug exception handler is incorporated from the beginning, so that there is no need to perform the processing of steps 314 to 316, and the process proceeds to step 317. .

If the breakpoint is not a breakpoint issued by the debug exception handler, the original code is written at the address where the breakpoint is specified (step 314). This is performed by extracting the original code of the address where the breakpoint occurred from the breakpoint table 230 in FIG. This allows the shared handler to exit
The original code will operate from the address where the breakpoint is set.

Further, it is determined whether or not the designation of a breakpoint is valid (step 315). This is done by examining the address of the breakpoint that caused the shared handler from the breakpoint address 231 in the breakpoint table 230 of FIG. If it is valid, the process proceeds to step 316. If it is invalid, the process proceeds to step 317.

In step 316, the single-step execution mode is set, and then the operation proceeds to step 317. The processing operation in the single-step execution mode is necessary when the breakpoint is repeatedly used. In other words, the rewritten breakpoint code is rewritten to the breakpoint code at this time by the exception handler called during the single step execution. The exception handler called during the single step execution will be described in detail with reference to FIG.

In step 317, the contents of the register saved in the processing in step 303 are restored. Then, the shared handler ends. By such a processing procedure of the shared handler, another memory space (second memory space) that cannot be caught by the breakpoint exception handler of the normal debugger 111
Breakpoints of the program 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 a processing procedure example for a debug exception called at the time of single step execution.

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

If the operation is in the first memory space 104, the process proceeds to the debug exception handler for the first memory space (step 402). Also, the first memory space 104
Otherwise, first, the contents of the register are saved in order to return to the state before the interruption later (step 403). Next, it is determined whether or not 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 the mode is not the debug mode, the program shifts to a debug exception handler normally used by the program in the second memory space 105 (step 405). If the debug mode has been activated, first, it is determined whether or not a breakpoint instruction has been written at the position of a breakpoint to be enabled (step 406). This determination is made based on whether or not the address at which the single-step execution has occurred is equal to the breakpoint address 231 of the breakpoint table 230 in FIG.

If there is an address determined here, a breakpoint instruction is written at that address (step 407). In this manner, by setting the breakpoints to be valid again, 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 because the single step execution stop mode flag 280 and the trace execution mode flag 281 of the common memory area 103 in FIG.
Is determined by the value of Here, the single step execution stop mode is a mode used for stopping and debugging each time a single step is executed.

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 the single-step execution, after the exception handler ends, the normal execution state is the same as that at the time of setting the breakpoint. Thereafter, the register is restored (step 410), and the debug exception handler ends. I do.

If the single-step execution is not canceled in the processing of step 408,
The contents of the register stored in the process of step 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 specifying a virtual address, the debugger 111 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 determined whether the single step execution stop mode is designated (step 41).
2). This is determined based on whether the single step execution stop mode flag 280 in FIG. 2 is designated. This processing is to stop each time a single step is executed, to see whether the state is viewed by a debugger, or to perform only a trace, and to determine whether to execute without stopping each time a single step is executed.

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

By issuing a breakpoint at step 414, it is possible to stop at a breakpoint each time a single step is executed, and the shared handler can capture breakpoints other than the memory space where the debugger is operating. The state in which the single step is executed in the second memory space 105 can be referred to by the debugger 111 operating in the first memory space 104.

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

In step 417, the trace data is stored in the trace table 25 of the shared area 103 in FIG.
Store to 0. As a result, the debugger 111 can refer to the trace data. In addition, the program can be referred to from the program in the first memory space 104. After the processing in step 417 or in step 416, if the trace execution mode has not been designated, the processing shifts to step 418.

In 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 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
Shift to the processing of 0.

The exception handler that performs the processing described in FIGS. 3 and 4 is common to programs in a multi-memory space, and an exception occurs at a breakpoint and single-step execution regardless of the difference in the memory space. Can be caught every time. Therefore, even in a multi-OS environment in which a plurality of programs each having a different virtual memory space operate in cooperation, it is possible to debug a program in the multi-memory space according to the order of the cooperative operation.

In debugging a program in a multi-memory space, the memory space information in the space information table is set, and the breakpoint table 230 is set for each memory space (104, 105). Can be easily dealt with.

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

Then, even in the 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 in the program in the second memory space is used as the debugger. By switching the space to the memory space in which the debugger operates, and issuing a breakpoint again, the debugger captures a breakpoint of a program in a different memory space.

Thus, a single debugger can debug a plurality of programs including an OS operating simultaneously in a multi-memory space (multi-memory space program), and can cooperate with a multi-memory space program. The debug technology of the present example can be used effectively, for example, for the development of an OS that operates in the second memory space. .

According to this embodiment, 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. This allows a debugger operating in the first memory space to capture single-step execution regardless of which memory space each program is in.

According to this embodiment, when single-step execution is set for each multi-memory space program, the exception handler for single-step execution stores trace data in the common memory area. It is possible to refer to the trace data of each program on one memory space.

Further, in this example, it is possible to capture data necessary for debugging by writing the data status of a program different from the memory space in which the debugger operates into a common memory area accessible from each memory space. 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 this can be referred to by the debugger or the application.

In this example, by preparing a flag for setting an 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. This makes it possible to distinguish between the exception handler used during debugging and the processing of the normally used exception handler without changing the code of the exception handler.

The present invention is not limited to the embodiment described with reference to FIGS. 1 to 4 and can be variously modified without departing from the gist thereof. For example, in this example, as shown in FIG.
The configuration is such that debugging is performed on the debug target computer 100 via the communication devices 114 and 108. This is because even if the debug target computer 100 goes down due to a failure in the OS of the debug target computer 100, the debug is performed.
The information is obtained so that the debugger 111 may be executed on the computer 100 to be debugged if there is no such danger.

[0065]

According to the present invention, a program including an OS (a multi-memory space program) operating simultaneously in a multi-memory space can be debugged by one debugger, and a cooperative operation of the multi-memory space program can be achieved. Multi-OS capable of debugging and operating multiple operating systems (OS) in different memory spaces on a single computer
It is possible to efficiently debug a multi-memory space program operating in an environment.

[Brief description of the drawings]

FIG. 1 is a block diagram showing an embodiment of a configuration according to the present invention of a debugging system for a multi-memory space program of the present invention.

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

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

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. 1;

[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 (a debugger targeting the first memory space), 1
12: input device, 113: output device, 114: communication device, 210: space 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
or Off)), 281: Trace execution mode flag (trace execution mode (On or Off)), 282: Single step execution determination flag (Single step execution determination (On or Off)).

Continued on the front page (72) Inventor Tomoki Sekiguchi 1099 Ozenji Temple, Aso-ku, Kawasaki City, Kanagawa Prefecture Inside System Development Laboratory, Hitachi, Ltd. (72) Toshiaki Arai 1099 Ozenji Temple, Ozenji, Aso-ku, Kawasaki City, Kanagawa Prefecture Hitachi, Ltd. Within the System Development Laboratory (72) Inventor Osamu Tomita 1 Ikegami, Haruoka-cho, Owariasahi-shi, Aichi Prefecture F-term (reference), Information Equipment Division, Hitachi, Ltd. 5B042 GA22 HH25 LA00 5B098 BA05 GA02 GD03 HH01 JJ06

Claims (12)

[Claims] A single computer can debug a program (multi-memory space program) including an OS operating in a multi-OS environment in which a plurality of operating systems (OS) each having a different memory space are linked to one OS. A system using a corresponding debugger, provided in a common memory area shared by each OS,
Triggered by a breakpoint exception that occurs in each memory space, and if the breakpoint exception occurs in a second memory space other than the first memory space of the OS on which the debugger operates, the second A memory space is switched from the memory space to the first memory space, a breakpoint is issued in the first memory space, and a breakpoint exception occurring in the second memory space corresponds to the first memory space. A debug system for a multi-memory space program, comprising: a breakpoint exception handler to be caught by a debugger operating on an OS. 2. A method in which a single computer debugs a program (multi-memory space program) including an OS operating in a multi-OS environment in which a plurality of operating systems (OSs) having different memory spaces are linked to each other. A method of debugging a multi-memory space program using a corresponding debugger, wherein a breakpoint exception handler (shared handler) having the following procedures is registered in a common memory area shared by each OS,
An OS on which the above-mentioned shared handler is activated by a breakpoint exception occurring in each memory space and the above-mentioned debugger operates
A method for debugging a multi-memory space program, wherein the breakpoint exception that has occurred in a second memory space other than the first memory space is captured by a debugger in the first memory space. (1) If the breakpoint exception occurs in the second memory space, a procedure for switching the memory space from the second memory space to the first memory space (2) Break in the switched first memory space Procedure for issuing points 3. A single computer can debug a program (multi-memory space program) including an OS operating in a multi-OS environment in which a plurality of operating systems (OS) each having a different memory space are linked to one OS. A method of debugging a multi-memory space program using a corresponding debugger, wherein a breakpoint exception handler (shared handler) having the following procedures is registered in a common memory area shared by each OS,
An OS on which the above-mentioned shared handler is activated by a breakpoint exception occurring in each memory space and the above-mentioned debugger operates
A debug method for a multi-memory space program, wherein the breakpoint exception generated in a second memory space other than the first memory space is captured by a debugger in the first memory space. (1) If the breakpoint exception occurs in the first memory space, a procedure for transferring processing to a breakpoint exception handler of the OS in the first memory space (2) The breakpoint exception is generated in the second memory space If the error occurs in the space and the debug mode is not set, the procedure is shifted to the OS breakpoint exception handler in the second memory space. (3) The breakpoint exception occurs in the second memory space, and If in debug mode, the second
Switching the memory space from the first memory space to the first memory space, and issuing a breakpoint in the switched first memory space 4. The multi-memory space program debugging method according to claim 2, further comprising: a table for registering an address for setting a breakpoint in the common memory area. A method for debugging a multi-memory space program, wherein the breakpoint is set and released using the table. 5. The method for debugging a multi-memory space program according to claim 2, wherein the debugger is configured to issue a breakpoint in the switched first memory space. After the breakpoint exception handler has finished processing,
From the first memory space to the second memory space based on the address information of the first memory space and the second memory space registered in the common memory area when switching from the memory space to the second memory space. A procedure for returning to the memory space, a procedure for returning the program code rewritten by issuing the breakpoint, a procedure for restarting the execution of the multi-memory space program in the second memory space, And setting a single-step execution based on an instruction registered in the common memory area in response to the breakpoint exception. 6. The method for debugging a multi-memory space program according to claim 5, wherein the single-step execution set by the shared handler resumes execution of the multi-memory space program in the second memory space. A debugging method for a multi-memory space program, characterized in that a debugging exception handler called when issued immediately after is registered in the common memory area and activated by all debugging exceptions occurring in each memory space. 7. The method for debugging a multi-memory space program according to claim 6, wherein the debug exception handler generates the debug exception if the debug exception occurs during debugging in the second memory space. A method of debugging a multi-memory space program, comprising a step of writing a breakpoint instruction to generate a breakpoint at an address position. 8. The method for debugging a multi-memory space program according to claim 6, wherein the debug exception handler includes a single-step execution stop instruction information set in the shared memory area. A method of debugging a multi-memory space program, comprising the steps of issuing the breakpoint and activating the shared handler. 9. The method for debugging a multi-memory space program according to claim 6, wherein the debug exception handler is configured to execute trace information based on trace execution instruction information set in the shared memory area. Into the trace data table in the common memory area, and before issuing the breakpoint,
Writing the register information into a register table in the common memory area. 10. The method for debugging a multi-memory space program according to claim 6, wherein instructions for debugging processing, instructions for stopping single-step execution, and instructions for tracing are registered in the common memory area. Characterized in that the above information is changed by the debugger or the multi-memory space program to change the processing procedure of the debug exception handler. 11. The method of debugging a multi-memory space program according to claim 2, wherein said shared handler writes register information in said common memory area before issuing said breakpoint. A method for debugging a multi-memory space program, comprising the steps of: 12. The method for debugging a multi-memory space program according to claim 2, wherein instructions for debugging processing, instructions for stopping single-step execution, and instructions for tracing are registered in said common memory area. A method of changing the processing procedure of the shared handler by changing each piece of information by the debugger or the multi-memory space program.