Method for debugging program of many core parallel processor based on code execution and apparatus using the same

Abstract

A method for debugging a program of a many-core parallel processor based on code execution and an apparatus for such debugging are disclosed. A method for debugging a program of a many-core parallel processor according to an embodiment of the present invention comprises: a step in which debugging software operating on a host processor generates a program execution binary including debugging execution code and provides said program execution binary to a plurality of parallel processors; a step in which context information corresponding to a state immediately prior to the execution of said debugging execution code is obtained for a target processor among the plurality of parallel processors where said debugging execution code is executed; and a step in which debugging is performed on a program executed on the processor where said debugging execution code is executed by analyzing said context information.

Description

Technology Field

[0001] The present invention relates to a program debugging technique for a many-core parallel processor based on code execution, and more specifically, to a debugging technique for a program executed on a parallel processor for computational processing in a many-core parallel processor system that utilizes a large number of parallel processors to accelerate massive computational processing. Background Technology

[0002] In conventional single processors, a hardware debug module is implemented inside the chip for debugging, and debugging is supported by communicating with debugging software on an external host.

[0003] At this time, Figure 1 shows a block diagram of a hardware debugging module of a RISC-V processor, which includes a Debug Transparent Module (DTM) for communicating with external debug software and a Debug Module (DM) for controlling the debugging of the processor inside the processor, and a Hardware Trigger Module for setting breakpoints and a Debug Mode are separately designed and implemented inside the processor core (RISC-V Core).

[0004] However, in large-scale parallel processor systems using thousands of processors, the implementation area of ​​hardware-implemented debug modules increases to an unnecessarily large extent, and because the actual frequency of use of such implemented debug modules is low, a problem arises in which the efficiency of the chip design decreases. Prior art literature

[0005] Korean Published Patent No. 10-2018-0054773, published May 24, 2018 (Title: Debugging method, multi-core processor, and debugging device) The problem to be solved

[0006] The objective of the present invention is to perform program debugging of each parallel processor without a hardware debug module in a large-scale parallel system using thousands or more processors. means of solving the problem

[0007] A method for debugging a program of a many-core parallel processor based on code execution according to the present invention for achieving the above-mentioned purpose comprises: a step in which debugging software operating on a host processor generates a program execution binary containing debugging execution code and provides said program execution binary to a plurality of parallel processors; a step in which context information corresponding to the state immediately before the execution of said debugging execution code is obtained for a target processor among the plurality of parallel processors where said debugging execution code is executed; and a step in which debugging of a program executed on the processor where said debugging execution code is executed is performed by analyzing said context information.

[0008] At this time, the debugging execution code may include a handler program that generates an interrupt command to stop the execution of the program and an interrupt to transfer the control flow to the debugging software.

[0009] At this time, the target processor may stop the execution of the program by the above execution suspension command and store the context information in a context memory buffer provided in the main memory based on the execution of the handler program.

[0010] At this time, context information can be stored in the context memory buffer at a location allocated by matching the identifier of the target processor.

[0011] At this time, the target processor stores the address value of the above execution suspension command in an internal register, and can resume the execution of the suspended program based on the address value stored in the internal register at the time when the handler program terminates.

[0012] At this time, the handler program generates the interrupt to transmit the fact that program execution on the target processor has been suspended to the debugging software, and can terminate when the interrupt is cleared by the debugging software.

[0013] At this time, when the interrupt is received, the debugging software can obtain the context information from the context memory buffer and perform analysis.

[0014] At this time, the debugging software can generate a program execution binary containing the debugging execution code by inserting the debugging execution code into a user-configured breakpoint (BREAKPOINT) in a general program execution binary generated by compiling the source program.

[0015] At this time, the debugging software may further include the step of deleting the debugging execution code inserted at the above-mentioned execution interruption location and reinserting the debugging execution code at a new execution interruption location according to the user's request to replace the program execution binary containing the debugging execution code.

[0016] At this time, when the debugging software receives a request from a user to execute new code for the purpose of debugging, it may further include the step of generating new code including the above execution suspension command at the end of the code and storing it in a debugging code memory buffer provided in the main memory; and the step of storing an address value corresponding to the starting position of the new code in the internal register.

[0017] At this time, when the handler program terminates, the target processor can execute the new code corresponding to the address value stored in the internal register.

[0018] Additionally, a debugging device according to one embodiment of the present invention includes: a host processor comprising debugging software that generates a program execution binary including debugging execution code, provides the program execution binary to a plurality of parallel processors, obtains context information corresponding to a state immediately prior to the execution of the debugging execution code for a target processor among the plurality of parallel processors where the debugging execution code is executed, and analyzes the context information to perform debugging on a program executed on the processor where the debugging execution code is executed; and a main memory shared by the host processor and the plurality of parallel processors.

[0019] At this time, the debugging execution code may include a handler program that generates an interrupt command to stop the execution of the program and an interrupt to transfer the control flow to the debugging software.

[0020] At this time, the target processor may stop the execution of the program by the above execution suspension command and store the context information in a context memory buffer provided in the main memory based on the execution of the handler program.

[0021] At this time, context information can be stored in the context memory buffer at a location allocated by matching the identifier of the target processor.

[0022] At this time, the target processor stores the address value of the above execution suspension command in an internal register, and can resume the execution of the suspended program based on the address value stored in the internal register at the time when the handler program terminates.

[0023] At this time, the handler program generates the interrupt to transmit the fact that program execution on the target processor has been suspended to the debugging software, and can terminate when the interrupt is cleared by the debugging software.

[0024] At this time, when the interrupt is received, the debugging software can obtain the context information from the context memory buffer and perform analysis.

[0025] At this time, the debugging software can generate a program execution binary containing the debugging execution code by inserting the debugging execution code into a user-configured breakpoint (BREAKPOINT) in a general program execution binary generated by compiling the source program.

[0026] At this time, the debugging software can replace the program execution binary containing the debugging execution code by deleting the debugging execution code inserted at the above-mentioned execution interruption location and reinserting the debugging execution code at a new execution interruption location according to the user's request.

[0027] At this time, when the debugging software receives a request from the user to execute new code for the purpose of debugging, it may generate new code including the above execution suspension command at the end of the code, store it in a debugging code memory buffer provided in the main memory, and store an address value corresponding to the starting position of the new code in the internal register.

[0028] At this time, when the handler program terminates, the target processor can execute the new code corresponding to the address value stored in the internal register. Effects of the invention

[0029] According to the present invention, program debugging of each parallel processor can be performed in a large-scale parallel system using thousands or more processors without a hardware debug module. Brief explanation of the drawing

[0030] Figure 1 is a diagram showing an example of a conventional hardware debug module (RISC-V Debug Support Specification). FIG. 2 is a diagram showing an example of a debugging system according to the present invention. FIG. 3 is an operation flowchart illustrating a program debugging method for a many-core parallel processor based on code execution according to an embodiment of the present invention. FIG. 4 is an operation flowchart illustrating an example of a process of providing a program execution binary to parallel processors according to the present invention. FIG. 5 is an operation flowchart illustrating the program debugging process of a many-core parallel processor according to the present invention. FIG. 6 is an operation flowchart showing an example of a process of executing new code for debugging purposes according to the present invention. FIG. 7 is a diagram structurally illustrating the program debugging process of a many-core parallel processor according to the present invention. FIG. 8 is a drawing showing a debugging device according to an embodiment of the present invention. Specific details for implementing the invention

[0031] The present invention will be described in detail below with reference to the accompanying drawings. Hereinafter, repetitive descriptions and detailed descriptions of known functions and configurations that may unnecessarily obscure the essence of the invention are omitted. Embodiments of the present invention are provided to more completely explain the invention to those with average knowledge in the art. Accordingly, the shapes and sizes of elements in the drawings may be exaggerated for clearer explanation.

[0032] In this document, each of the phrases such as "A or B", "at least one of A and B", "at least one of A or B", "A, B or C", "at least one of A, B and C", and "at least one of A, B, or C" may include any one of the items listed together in the corresponding phrase, or all possible combinations thereof.

[0033] Hereinafter, preferred embodiments according to the present invention will be described in detail with reference to the attached drawings.

[0035] Although the debugging function for programs running on processor cores is very useful for software developers, it is utilized very infrequently in actual processor usage. In a single processor core, only one hardware debug module needs to be implemented for that core, so the implementation area is not large. However, in many-core parallel processors that perform parallel processing using thousands of processors, the implementation cost (area, wiring) of the hardware debug module becomes a serious problem.

[0036] Therefore, the present invention proposes a method that enables debugging of each program running on thousands of parallel processors without implementing a hardware debug module.

[0038] FIG. 2 is a diagram showing an example of a debugging system according to the present invention.

[0039] Referring to FIG. 2, the debugging system according to the present invention may be composed of a host processor (210) on which debugging software (211) operates, a plurality of parallel processors (220-1 to 220-N), and a main memory (230) shared by the host processor (210) and the plurality of parallel processors (220-1 to 220-N).

[0040] Below, we will explain the functional blocks that make up each module and the role of each block through [Table 1].

[0041] Function Block explanation Kernel.c Source code of a program running on multiple parallel processors (Core#0~Core#N) Debugger(SW) Debugging software for programmers of software running on a host processor HOST Processor A host processor where the OS, user applications, and Debugger (SW) run Core#0~Core#N A many-core parallel processor that executes programs written in Kernel.c in parallel to accelerate large-scale computation processing Memory System main memory shared by the Host Processor and multiple parallel processors (Core#0~Core#N) Kernel.exe The program execution binary generated by compiling the Kernel.c source code kernel.dbg A program execution binary generated by inserting break.instr into the Kernel.exe execution binary and adding break.handler code break.instr When the instruction is executed as one of the instructions running on multiple parallel processors (Core#0~Core#N), the running program is interrupted and the break.handler program is executed. break.handler The program executed by break.instr on multiple parallel processors (Core#0~Core#N) (included in the Kernel.dbg binary) executes the program corresponding to the address stored in debug.PC after the break.handler execution is complete. debug.context A memory buffer to store context data from the state immediately prior to the execution of break.instr of the Core where break.instr and break.handler were executed; stores the contents of general-purpose registers, stacks, etc. of the Cores currently being debugged. debug.code A memory buffer used to store program code to be executed on a specific core during the debugging process in the debugger (SW). Entrypoint The address value of the program that each of the multiple parallel processors (Core #0~Core #N) initially executes. When the Host Processor writes the address value to the Entrypoint register, the corresponding Core starts the program from the Entrypoint. debug.PC When break.instr is executed, the PC value (instruction address) of break.instr is stored in debug.PC, and after the break.handler program finishes, the program resumes execution from the address stored in debug.PC. Core.ID The currently executing Core can be identified by checking the Core.ID value in the registerKernel program inside the Core, which stores ID values ​​that distinguish and identify multiple parallel processors (Core#0~Core#N).

[0043] FIG. 3 is an operation flowchart illustrating a program debugging method for a many-core parallel processor based on code execution according to an embodiment of the present invention.

[0044] Referring to FIG. 3, a program debugging method for a many-core parallel processor based on code execution according to an embodiment of the present invention comprises debugging software operating on a host processor, which generates a program execution binary including debugging execution code and provides the program execution binary to a plurality of parallel processors (S310).

[0045] At this time, the debugging software can generate a program execution binary containing debugging execution code by inserting debugging execution code into a user-configured breakpoint (BREAKPOINT) in the general program execution binary generated by compiling the source program.

[0046] For example, debugging software (211) operated by a user on the host processor (210) shown in FIG. 2 can compile the Kernel.c source program to generate a Kernel.exe binary in the form of [Table 2].

[0047] / / Kernel.exe Instruction.0Instruction.1Instruction.2Instruction.3Instruction.4Instruction.5...

[0048] Afterwards, the debugging software (211) shown in FIG. 2 can generate a Kernel.dbg binary containing debugging execution code by inserting break.instr as shown in [Table 3] into the part corresponding to the user-set breakpoint in the Kernel.exe binary shown in [Table 2] and adding break.handler code.

[0049] / / Kernel.dbg Instruction.0Instruction.1Instruction.2Instruction.3Instruction.4 break.instr Instruction.5... / / beark.handler Save Core context to debug.contextSend IRQ to HostWait for IRQ cleared Set PC <- debug.PC Continue execution

[0050] In this case, the debugging execution code may include a handler program that generates an interrupt command to stop the execution of the program and an interrupt to transfer the control flow to the debugging software.

[0051] For example, referring to [Table 3], break.instr corresponds to a break command, and break / handler corresponds to code in a handler program.

[0052] At this time, the debugging software according to one embodiment of the present invention can set the Entrypoint of each processor by distinguishing between the processor performing debugging and the processor not performing debugging among a plurality of parallel processors, after mounting a general program execution binary (kernel.exe) that does not include debugging execution code and a program execution binary (kernel.dbg) that includes debugging execution code on the main memory, respectively.

[0053] For example, the debugging software (211) illustrated in FIG. 2 can load Kernel.exe binary data that does not contain debugging execution code and Kernel.dbg binary data that contains debugging execution code onto the main memory (230), respectively. Afterward, the starting address of the Kernel.exe binary can be set in the Entrypoint register of a processor among the plurality of parallel processors (220-1 to 220-N) that is not performing debugging, and the starting address of the Kernel.dbg binary can be set in the Entrypoint register of a core among the plurality of parallel processors (220-1 to 220-N) that is performing debugging.

[0054] Therefore, for processors that are not being debugged, the Kernel.exe binary can be executed to allow program execution to proceed without a break, whereas for processors that are being debugged, the Kernel.dbg binary can be executed to break the program when break.instr is encountered.

[0055] In addition, a program debugging method for a many-core parallel processor based on code execution according to an embodiment of the present invention, the debugging software obtains context information corresponding to the state immediately before the debugging execution code is executed, targeting a target processor among a plurality of parallel processors where the debugging execution code is executed (S320).

[0056] At this time, the target processor can stop the execution of the program by means of a suspension command and store context information in a context memory buffer provided in main memory based on the execution of the handler program.

[0057] In this case, context information can be stored in a location allocated in the context memory buffer that matches the identifier of the target processor.

[0058] For example, referring to FIG. 2, when the target processor encounters a break command (break.instr) during program execution, it can stop the program execution, save the address value (PC value) of the break.instr command in the internal debug.PC register, and then execute the code of the handler program (break.handler). Afterward, the handler program (break.handler) can save context information (context data), including the target processor's general purpose registers, stack, debug.PC, etc., into the context memory buffer (debug.context) just before the break command (break.instr) is executed. At this time, the context information (context data) can be saved to the location allocated to the target processor in the debug.context memory buffer using the Core.ID value corresponding to the target processor.

[0059] At this time, the handler program generates an interrupt to notify the debugging software of the suspension of program execution on the target processor, and can terminate when the interrupt is cleared by the debugging software.

[0060] For example, the handler program (break.handler) illustrated in FIG. 2 can generate an interrupt (IRQ) to notify the debugging software (211) of the host processor (210) of the fact that the target processor has stopped execution. Afterward, the handler program (break.handler) can wait without performing any action until the IRQ is cleared.

[0061] In addition, a program debugging method for a many-core parallel processor based on code execution according to an embodiment of the present invention, the debugging software analyzes context information and performs debugging on a program executed on a processor where the debugging execution code is executed (S330).

[0062] At this time, when an interrupt is received, the debugging software can obtain context information from the context memory buffer and perform analysis.

[0063] For example, debugging software (211) that receives an IRQ can retrieve context information (debug.context) from a context memory buffer (debug.context) on the main memory (230) and perform analysis. At this time, the user of the host processor (210) can check the analysis results and proceed with debugging the subsequent process, and in this process, the values ​​of program variables, etc., may be analyzed.

[0064] At this time, the target processor stores the address of the execution suspension instruction in an internal register, and can resume the execution of the suspended program based on the address stored in the internal register when the handler program terminates.

[0065] For example, the break.handler shown in FIG. 2 can return the control flow to the instruction at the address of the debug.PC value by hardware-setting the debug.PC value to the PC value after the operation is finished.

[0066] After this, the target processor can resume program execution through the program execution binary and continue instruction execution until it encounters break.instr.

[0067] At this time, the debugging software can replace the program execution binary containing the debugging execution code by deleting the debugging execution code inserted at the breakpoint and reinserting the debugging execution code at a new breakpoint according to the user's request.

[0068] For example, if a user of a host processor requests additional functions such as Step, Step-In, Step-Out, or breakpoint at function, the debugging software (211) shown in FIG. 2 can delete the break.instr previously entered into the Kernel.dbg binary shown in [Table 3]. Afterward, a new Kernel.dbg binary can be created by inserting break.instr again into the breakpoint newly requested by the user. The newly created Kernel.dbg binary can be mounted by replacing the location of the existing Kernel.dbg binary stored in the main memory (230).

[0069] At this time, when the debugging software receives a request from the user to execute new code for the purpose of debugging, it may generate new code including a stop-execution command at the end of the code, store it in a debugging code memory buffer provided in the main memory, and store an address value corresponding to the starting position of the new code in an internal register.

[0070] At this time, when the handler program terminates, the target processor can execute new code corresponding to the address value stored in the internal register.

[0071] For example, if a user requests to execute additional new code for debugging purposes, the debugging software (211) illustrated in FIG. 2 can generate new code (debug.code) with a structure as shown in [Table 4] and load it into the debugging code memory buffer on the main memory (230). Afterward, by inserting break.instr as the last command of the new code (debug.code), the control flow can be returned to the debugging software (211) after the execution of the new code (debug.code).

[0072] / / debug.code {...Instructions... break.instr }

[0073] At this time, the debugging software (211) can load the new code (debug.code) into the debugging code memory buffer of the main memory and then set the debug.PC value of the target processor to the starting address of the new code (debug.code). After that, the IRQ can be cleared so that the handler program (break.handler) is terminated, and after the handler program (break.handler) is terminated, the instructions at the address pointed to by the debug.PC value can be executed so that the instructions of the new code (debug.code) are executed in the target processor.

[0074] Through a program debugging method for many-core parallel processors based on such code execution, it is possible to debug the programs of each parallel processor in a large-scale parallel system using thousands or more processors without a hardware debug module.

[0076] FIG. 4 is an operation flowchart illustrating an example of a process of providing a program execution binary to parallel processors according to the present invention.

[0077] Referring to FIG. 4, the process of providing a program execution binary to parallel processors according to the invention first involves debugging software operated by a user on a host processor compiling the Kernel.c source program to generate a Kernel.exe binary in the form of [Table 2] (S410).

[0078] Afterwards, the debugging software can generate kernel.dbg binary code containing debugging execution code by inserting break.instr as shown in [Table 3] into the part corresponding to the user-set breakpoint in the Kernel.exe binary shown in [Table 2] and adding break.handler code (S420).

[0079] After this, the starting address of the kernel.dbg binary can be set in the Entrypoint register of the processor performing the debugging among the multiple parallel processors (S430).

[0080] For the processor to be debugged through this process, the program execution can be stopped (break) when break.instr is encountered by running the Kernel.dbg binary.

[0082] FIG. 5 is an operation flowchart illustrating the program debugging process of a many-core parallel processor according to the present invention.

[0083] Referring to FIG. 5, the program debugging process of a many-core parallel processor according to the present invention can be specifically divided into operations in a parallel processor, a handler program (break.handler), and debugging software (debugger(SW)).

[0084] First, the kernel.dbg binary is executed on a parallel processor (target processor) in which the starting address of the kernel.dbg binary is set in the Entrypoint register through a process as shown in Fig. 4 (S510), and it can be determined whether break.instr is executed during program execution (S515).

[0085] If the result of the judgment in step (S515) is that break.instr was not executed, the program can continue to execute and determine whether break.instr was executed.

[0086] Additionally, if break.instr is executed as a result of the judgment in step (S515), the execution of the currently running program is interrupted (break) (S520), the address value (PC value) of the break.instr instruction is stored in the internal debug.PC register (S530), and the code of the handler program (break.handler) can be executed (S540).

[0087] Afterwards, the handler program (break.handler) can save context information (context data), including the target processor's general purpose registers, stack, debug.PC, etc., to the context memory buffer (debug.context) just before the break command (break.instr) is executed (S550).

[0088] After this, the handler program can generate an interrupt to transmit the fact that program execution on the target processor has been interrupted to the debugging software (S560).

[0089] After this, the debugging software can analyze the context information (contest data) and perform debugging on the program executed on the processor where the debugging execution code was executed (S570).

[0091] FIG. 6 is an operation flowchart showing an example of a process of executing new code for debugging purposes according to the present invention.

[0092] Referring to FIG. 6, the process of executing new code for debugging purposes according to the present invention first involves the debugging software generating new code (debug.code) with a structure as shown in [Table 4] when a user requests to execute additional new code for debugging purposes (S610).

[0093] In this case, by inserting break.instr as the very last command of the new code (debug.code), the control flow can be returned to the debugging software after the execution of the new code (debug.code).

[0094] After this, the debugging software can load the new code (debug.code) into the debugging code memory buffer of the main memory and then set the debug.PC value of the target processor to the starting address of the new code (debug.code) (S620).

[0095] After this, the IRQ can be cleared to allow the handler program (break.handler) to terminate (S630), and after the handler program (break.handler) terminates, the instructions at the address pointed to by the debug.PC value can be executed, thereby allowing the instructions of the new code (debug.code) to be executed on the target processor (S640).

[0097] FIG. 7 is a diagram structurally illustrating the program debugging process of a many-core parallel processor according to the present invention.

[0098] Referring to FIG. 7, the program debugging process of a many-core parallel processor according to the present invention first involves a debugging software (Debugger SW) operating on a host processor compiling a Kernel.c source program to generate a Kernel.exe binary in the form of [Table 2] (S702).

[0099] Afterwards, the debugging software can generate a Kernel.dbg binary containing debugging execution code by inserting break.instr as shown in [Table 3] into the part corresponding to the user-set breakpoint in the Kernel.exe binary shown in [Table 2] and adding break.handler code (S704).

[0100] After this, debugging software can provide the Kernel.dbg binary to multiple parallel processors (Core#0~Core#N), and the multiple parallel processors can execute a program by setting the starting address of the Kernel.dbg binary in the Entrypoint register (S706).

[0101] After this, if break.instr is encountered during program execution, the program can be interrupted (break) and a handler program (break.handler) can be executed (S710).

[0102] At this time, the handler program can generate an interrupt (IRQ) to notify the debugging software of the fact that program execution has been interrupted.

[0103] After this, the debugging software analyzes the context information (S712) and, in response to the user's request, can modify the Kernel.dbg binary (S714) or generate and execute new code (debug.code) (S716).

[0104] For example, if a user of the host processor requests additional functions such as Step, Step-In, Step-Out, or breakpoint at function, the debugging software can delete the break.instr previously entered into the Kernel.dbg binary. Subsequently, the Kernel.dbg binary can be modified by inserting break.instr again at the breakpoint newly requested by the user. The modified Kernel.dbg binary can then be mounted by replacing the location of the existing Kernel.dbg binary stored in main memory.

[0105] As another example, if a user requests to execute additional new code for debugging purposes, the debugging software can generate new code (debug.code) with a structure as shown in [Table 4] and load it into the debugging code memory buffer in main memory. Afterward, by inserting break.instr as the last command of the new code (debug.code), the control flow can be returned to the debugging software after the execution of the new code (debug.code).

[0106] After this, the IRQ can be cleared to allow the handler program (break.handler) to terminate, and after the handler program (break.handler) terminates, the control flow can be returned to the instruction at the address pointed to by the debug.PC value by executing the instruction at the address of the debug.PC value (S718).

[0108] FIG. 8 is a drawing showing a debugging device according to an embodiment of the present invention.

[0109] Referring to FIG. 8, a debugging device according to one embodiment of the present invention may be implemented in a computer system such as a computer-readable recording medium. As illustrated in FIG. 8, the computer system (800) may include one or more processors (810), memory (830), user input device (840), user output device (850), and storage (860) that communicate with each other via a bus (820). Additionally, the computer system (800) may further include a network interface (870) connected to a network (880). The processor (810) may be a semiconductor device that executes processing instructions stored in a central processing unit or memory (830) or storage (860). The memory (830) and storage (860) may be various forms of volatile or non-volatile storage media. For example, the memory may include ROM (831) or RAM (832).

[0110] Accordingly, embodiments of the present invention may be implemented as a computer-implemented method or as a non-transient computer-readable medium on which computer-executable instructions are recorded. When computer-readable instructions are executed by a processor, computer-readable instructions may perform a method according to at least one aspect of the present invention.

[0111] At this time, the processor (810) may be the host processor of the present invention.

[0112] The processor (810) may include debugging software that generates a program execution binary containing debugging execution code, provides the program execution binary to a plurality of parallel processors, obtains context information corresponding to the state immediately before the debugging execution code is executed for a target processor among the plurality of parallel processors where the debugging execution code is executed, analyzes the context information, and performs debugging on a program executed on a processor where the debugging execution code is executed.

[0113] At this time, the debugging software can generate a program execution binary containing debugging execution code by inserting debugging execution code into a user-configured breakpoint (BREAKPOINT) in the general program execution binary generated by compiling the source program.

[0114] In this case, the debugging execution code may include a handler program that generates an interrupt command to stop the execution of the program and an interrupt to transfer the control flow to the debugging software.

[0115] At this time, the debugging software according to one embodiment of the present invention can set the Entrypoint of each processor by distinguishing between the processor performing debugging and the processor not performing debugging among a plurality of parallel processors, after mounting a general program execution binary (kernel.exe) that does not include debugging execution code and a program execution binary (kernel.dbg) that includes debugging execution code on the main memory, respectively.

[0116] At this time, the target processor can stop the execution of the program by means of a suspension command and store context information in a context memory buffer provided in main memory based on the execution of the handler program.

[0117] In this case, context information can be stored in a location allocated in the context memory buffer that matches the identifier of the target processor.

[0118] At this time, the handler program generates an interrupt to notify the debugging software of the suspension of program execution on the target processor, and can terminate when the interrupt is cleared by the debugging software.

[0119] At this time, when an interrupt is received, the debugging software can obtain context information from the context memory buffer and perform analysis.

[0120] At this time, the target processor stores the address of the execution suspension instruction in an internal register, and can resume the execution of the suspended program based on the address stored in the internal register when the handler program terminates.

[0121] At this time, the debugging software can replace the program execution binary containing the debugging execution code by deleting the debugging execution code inserted at the breakpoint and reinserting the debugging execution code at a new breakpoint according to the user's request.

[0122] At this time, when the debugging software receives a request from the user to execute new code for the purpose of debugging, it may generate new code including a stop-execution command at the end of the code, store it in a debugging code memory buffer provided in the main memory, and store an address value corresponding to the starting position of the new code in an internal register.

[0123] At this time, when the handler program terminates, the target processor can execute new code corresponding to the address value stored in the internal register.

[0124] By using such a debugging device, program debugging of each parallel processor can be performed in large-scale parallel systems using thousands or more processors without a hardware debug module.

[0126] As described above, the method for program debugging of a many-core parallel processor based on code execution and the apparatus for the same according to the present invention are not limited to the configurations and methods of the embodiments described above; rather, all or part of each embodiment may be selectively combined to allow for various modifications of the embodiments. Explanation of the symbols

[0127] 210: Host processor 211: Debugging software 220-1~220-N: Parallel processors 230: Main memory 800: Computer system 810: Processor 820: Bus 830: Memory 831: ROM 832: RAM 840: User input device 850: User output device 860: Storage 870: Network Interface 880: Network

Claims

Claim 1 A method for debugging a program of a many-core parallel processor, wherein debugging software operating on a host processor generates a program execution binary containing debugging execution code and provides the program execution binary to a plurality of parallel processors; obtains context information corresponding to the state immediately before the execution of the debugging execution code with respect to a target processor among the plurality of parallel processors where the debugging execution code is executed; and analyzes the context information to perform debugging on a program executed on a processor where the debugging execution code is executed, wherein the debugging execution code includes a handler program that generates an interrupt command to stop the execution of the program and an interrupt to transfer control flow to the debugging software, and the target processor stops the execution of the program by the interrupt command and stores the context information in a context memory buffer provided in main memory based on the execution of the handler program, and the context information includes a program counter (PC) immediately before the execution of the debugging execution code, a general-purpose register (GPR) value, a stack pointer (SP), a core identifier (Core ID) currently executing, and trigger information of the debugging execution code. Claim 2 delete Claim 3 delete Claim 4 A method for debugging a program of a many-core parallel processor according to claim 1, wherein the context information is stored in a location allocated in the context memory buffer that matches the identifier of the target processor. Claim 5 A method for debugging a program of a many-core parallel processor according to claim 1, wherein the target processor stores the address value of the execution suspension command in an internal register and resumes the execution of the suspended program based on the address value stored in the internal register at the time when the handler program terminates. Claim 6 A method for debugging a program of a many-core parallel processor according to claim 5, wherein the handler program generates the interrupt to transmit the fact that the program execution in the target processor has been suspended to the debugging software, and terminates when the interrupt is cleared by the debugging software. Claim 7 A method for debugging a program of a many-core parallel processor according to claim 1, wherein the debugging software obtains context information from the context memory buffer and performs analysis when the interrupt is received. Claim 8 A method for debugging a program of a many-core parallel processor according to claim 1, wherein the debugging software generates a program execution binary containing the debugging execution code by inserting the debugging execution code into a user-configured execution breakpoint (BREAKPOINT) for debugging in a general program execution binary generated by compiling a source program. Claim 9 A method for debugging a program of a many-core parallel processor according to claim 8, further comprising the step of the debugging software deleting the debugging execution code inserted at the execution interruption location and reinserting the debugging execution code at a new execution interruption location according to a user's request to replace the program execution binary containing the debugging execution code. Claim 10 A method for debugging a program of a many-core parallel processor according to claim 5, wherein the debugging software, when requested by a user to execute new code for the purpose of debugging, generates new code including the execution suspension command at the end of the code and stores it in a debugging code memory buffer provided in the main memory; and further comprises the step of storing an address value corresponding to the start position of the new code in the internal register. Claim 11 A method for debugging a program of a many-core parallel processor according to claim 10, wherein the target processor executes the new code corresponding to the address value stored in the internal register when the handler program is terminated. Claim 12 A debugging device comprising: a host processor including debugging software that generates a program execution binary containing debugging execution code, provides the program execution binary to a plurality of parallel processors, obtains context information corresponding to the state immediately before the debugging execution code is executed for a target processor among the plurality of parallel processors where the debugging execution code is executed, and analyzes the context information to perform debugging on a program executed on the processor where the debugging execution code is executed; and a main memory shared by the host processor and the plurality of parallel processors, wherein the debugging execution code includes a handler program that generates an interrupt command to stop the execution of the program and an interrupt to transfer control flow to the debugging software, the execution of the program is stopped by the interrupt command, and the context information is stored in a context memory buffer provided in the main memory based on the execution of the handler program, and the context information includes a program counter (PC), a general-purpose register (GPR) value, a stack pointer (SP), a core identifier (Core ID) currently executing, and trigger information of the debugging execution code immediately before the debugging execution code is executed. Claim 13 delete Claim 14 delete Claim 15 A debugging device according to claim 12, characterized in that the context information is stored in a location allocated in the context memory buffer that matches the identifier of the target processor. Claim 16 A debugging device according to claim 12, wherein the target processor stores the address value of the execution suspension command in an internal register and resumes the execution of the suspended program based on the address value stored in the internal register at the time when the handler program terminates. Claim 17 A debugging device according to claim 16, characterized in that the handler program generates the interrupt to transmit the fact that program execution in the target processor has been suspended to the debugging software, and terminates when the interrupt is cleared by the debugging software. Claim 18 A debugging device according to claim 12, wherein the debugging software obtains context information from the context memory buffer and performs analysis when the interrupt is received. Claim 19 A debugging device according to claim 12, wherein the debugging software generates a program execution binary containing the debugging execution code by inserting the debugging execution code into a user-configured execution breakpoint (BREAKPOINT) for debugging in a general program execution binary generated by compiling a source program. Claim 20 A debugging device according to claim 19, wherein the debugging software deletes the debugging execution code inserted at the execution interruption location and re-inserts the debugging execution code at a new execution interruption location according to a user's request to replace the program execution binary containing the debugging execution code.

Images