A heterogeneous multi-core software debugging device and debugging method

Abstract

The present invention discloses a heterogeneous multi-core software debugging device and debugging method, including the following configurations: a slave core debugging agent thread sdbth: sdbth is created by a master core OS, runs in the address space of a traced process tracee, and cyclically executes a low-priority sleep; a set of slave core architecture data and a switch are added to the debugger process debug; the slave core architecture data includes disassembly, reading and writing of hardware registers, insertion and deletion of hardware breakpoints, and address calculation of the next instruction in a software single-step algorithm; the switch is used to control the switching of the two processor architectures of the master core and the slave core. The present invention can realize execution tracking and error location of heterogeneous parallel codes.

Description

Technical Field

[0001] The present invention relates to a heterogeneous multi-core software debugging device and a debugging method, and belongs to the field of high performance computing. Background Art

[0002] Software debugging tools provide basic debugging functions such as breakpoints, single-stepping, and printing. They execute the debugged program in segments, and the segmentation granularity can range from one instruction to a program segment. In addition to a series of debugging functions, users can also explore more debugging skills in the application. The debugging tool is an architecture-related software. The software and hardware adaptation process is relatively complex. The microstructure and interrupt exception mechanism of the processor, the debugging interface of the operating system, the debugging information specification of the language compiler, and the runtime library are all related to it. The debugging tool has developed from a single-core processor to a multi-core processor. According to a fixed processor hardware architecture, it controls and understands the operation of the program. Existing software debugging tools control and understand the operation of the program according to a fixed processor hardware architecture. At the same time, the OS debugging interface they rely on can only be oriented to traditional Linux threads and does not support the debugging of hardware threads. The two processor units of the heterogeneous multi-core processor have different microstructures and interrupt mechanisms. This complexity makes all current open source debugging software unable to support heterogeneous processor architectures or software debugging from the core.

[0003] Currently, parallel computing has widely adopted low-power and high-performance accelerated computing based on heterogeneous many-cores, while the software debugger tools released by the open source community are still in the multi-core processor version. Among them, Gdb is a widely used and actively updated open source software on Linux. It supports source code level debugging of mainstream programming languages ​​and software debugging of many mainstream multi-core processors. However, no version for mainstream many-core chips has been released, and the software debugging technology related to the many-core architecture is also very immature. The software development in this area lags behind the development of hardware architecture. Summary of the invention

[0004] The purpose of the present invention is to provide a heterogeneous many-core software debugging device and a debugging method, which can realize execution tracking and error location of heterogeneous parallel codes.

[0005] In order to achieve the above object, the technical solution adopted by the present invention is: to provide a heterogeneous multi-core software debugging device, characterized in that it includes the following configurations:

[0006] From the core debug agent thread sdbth:

[0007] sdbth is created by the main core OS, runs in the address space of the traced process tracee, and executes a low-priority sleep cycle;

[0008] When the slave core issues an interrupt request to the master core, sdbth is woken up, wherein the interrupt request includes a debug interrupt request and an I / O request;

[0009] After sdbth is awakened, it continues to execute the sleeping system call in the OS kernel state and sends a debugging signal to itself;

[0010] When returning from kernel mode to user mode, OS checks for debug signals and finds the process trace flag TF, thus waking up the debugger process debug;

[0011] After the debugger process debug is awakened, it obtains the execution control of the slave core program;

[0012] If the interrupt request is an I / O request, the interrupt request is returned to the process tracee and processed according to the OS default method, that is, the processing process originally set for the I / O request is completed;

[0013] If the interrupt request is a slave core debugging interrupt request, the breakpoint scene is analyzed and returned to the user to manually check the execution status of the slave core program stopped at the breakpoint;

[0014] Add a set of slave core architecture data and a switch in the debugger process debug;

[0015] From the core architecture data, this includes disassembly, reading and writing hardware registers, inserting and deleting hardware breakpoints, and calculating the address of the next instruction in the software single-step algorithm;

[0016] The switch is used to control the switching between the main core and the slave core processor architecture.

[0017] The further improved scheme in the above technical scheme is as follows:

[0018] The creation timing of the slave core debugging agent thread sdbth includes the following two situations:

[0019] When the application executes to the slave core parallel initialization, if the debugged flag TF is set, the slave core runtime library creates sdbth after completing the slave core resource application and terminates sdbth after the slave core resources are released. Otherwise, sdbth is not created.

[0020] The main core OS adds a / proc / lwpid / scoreid file, where lwpid is the thread number and scoreid is the file name. When creating sdbth, the corresponding scoreid file is created according to the requested slave core resources. If -1 is stored in the scoreid file, the thread specified by lwpid is another debugged user thread on the main core. If a non-negative integer is stored in the scoreid file, lwpid indicates the slave core number, and the lwpid is sdbth.

[0021] When creating sdbth, the corresponding slave core number is stored in the scoreid file, and the data of the scoreid file of threads created elsewhere is initialized to -1, indicating the master core thread;

[0022] Before the debugger process debug executes the traditional attach process, a contract signal is sent to tracee. Tracee executes the interrupt processing function of the contract signal in the kernel runtime library. The interrupt processing function creates sdbth. Before debug executes the traditional detach process, sdbth is terminated.

[0023] A heterogeneous multi-core software debugging method is also provided, based on the above heterogeneous multi-core software debugging device, characterized in that it includes the following steps:

[0024] S1. The debug process forks a child process, namely the tracee process, sets its debug flag TF, and establishes a control relationship between the debug process and the debugged process;

[0025] S2, the tracee process executes the debugged heterogeneous program and completes the slave core resource application and space initialization;

[0026] S3. When TF is true, the tracee process creates a debugging agent thread sdbth corresponding to each slave core and writes the slave core number in the scorid file;

[0027] S4. The Debug process captures the threads of the tracee process space one by one;

[0028] S5. The debug process finds the sdbth thread whose scorid is non-negative, and establishes a control relationship between sdbth and the corresponding slave core;

[0029] S6, Debug process initializes the architecture data for controlling slave core debugging;

[0030] S7, the debug process determines whether the breakpoint set by the user is the breakpoint of the master core or the slave core according to the address range of the slave core text segment;

[0031] S8. The debug process sets the main core breakpoint according to the main core architecture;

[0032] S9. The debug process sets slave core breakpoints according to the slave core architecture.

[0033] S10, the debug process resumes the tracee process;

[0034] S11, the tracee process runs to the slave core hardware breakpoint and sends a debug interrupt to the master core;

[0035] S12, the operating system processes the interrupt, sets the slave core debug interrupt flag, and sends a debug signal to the sdbth thread;

[0036] S13, the debug process is awakened by the debug signal of sdbth, the interrupt flag is determined, the master-slave core architecture data is switched, and the hardware architecture data structure is converted and switched to the slave core architecture data structure;

[0037] S14, the debug process converts the hardware scene into the corresponding slave core program scene. The specific conversion method is the same as the main core debugging;

[0038] S15. The Debug process exits and sdbth is terminated.

[0039] A heterogeneous multi-core software debugging method is also provided, based on the above heterogeneous multi-core software debugging device, characterized in that it includes the following steps:

[0040] S1. The debug process finds the process number of the running heterogeneous program;

[0041] S2. The debug process sends a specified signal to the running tracee process. The tracee process enters the interrupt processing function that executes the specified signal in the kernel runtime library. The interrupt processing function creates sdbth.

[0042] S3. The Debug process captures the threads of the tracee process space one by one;

[0043] S4. The debug process finds the sdbth thread whose scorid is non-negative, and establishes a control relationship between sdbth and the corresponding slave core;

[0044] S5, the debug process initializes the architecture data that controls the slave core debugging;

[0045] S6, the debug process determines whether the breakpoint set by the user is the breakpoint of the master core or the slave core according to the address range of the slave core text segment;

[0046] S7, Debug process sets the main core breakpoint according to the main core architecture;

[0047] S8. The debug process sets slave core breakpoints according to the slave core architecture;

[0048] S9, the debug process resumes the tracee process;

[0049] S10, the tracee process runs to the slave core hardware breakpoint and sends a debug interrupt to the master core;

[0050] S11, the operating system processes the interrupt, sets the slave core debug interrupt flag, and sends a debug signal to the sdbth thread;

[0051] S12, the Debug process is awakened by the debugging signal of sdbth, determines the interrupt flag, switches the master-slave core architecture data, and converts the hardware architecture data structure into the slave core architecture data structure;

[0052] S13, the debug process converts the hardware scene into the corresponding slave core program scene. The specific conversion method is the same as the main core debugging;

[0053] S14. The Debug process exits and sdbth is terminated.

[0054] Due to the application of the above technical solution, the present invention has the following advantages compared with the prior art:

[0055] The present invention proposes a heterogeneous many-core software debugging device and a debugging method, which can realize execution tracking and error location of heterogeneous parallel codes, and can reuse the existing code architecture of open source software gdb, and has good portability and feasibility. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] Attached Figure 1 The present invention is a schematic diagram of a heterogeneous multi-core software debugging device. DETAILED DESCRIPTION

[0057] Embodiment: The present invention provides a heterogeneous multi-core software debugging device, characterized in that it includes the following configurations:

[0058] From the core debug agent thread sdbth:

[0059] sdbth is created by the main core OS, runs in the address space of the traced process tracee, and executes a low-priority sleep cycle;

[0060] When the slave core issues an interrupt request to the master core, sdbth is woken up, wherein the interrupt request includes a debug interrupt request and an I / O request;

[0061] After sdbth is awakened, it continues to execute the sleeping system call in the OS kernel state and sends a debugging signal to itself;

[0062] When returning from kernel mode to user mode, OS checks for debug signals and finds the process trace flag TF, thus waking up the debugger process debug;

[0063] After the debugger process debug is awakened, it obtains the execution control of the slave core program;

[0064] If the interrupt request is an I / O request, the interrupt request is returned to the process tracee and processed according to the OS default method, that is, the processing process originally set for the I / O request is completed;

[0065] If the interrupt request is a slave core debugging interrupt request, the breakpoint scene is analyzed and returned to the user to manually check the execution status of the slave core program stopped at the breakpoint;

[0066] The creation timing of the slave core debugging agent thread sdbth includes the following two situations:

[0067] When the application executes to the slave core parallel initialization, if the debugged flag TF is set, the slave core runtime library creates sdbth after completing the slave core resource application and terminates sdbth after the slave core resources are released. Otherwise, sdbth is not created.

[0068] The sdbth thread also has a normal Linux thread number (lwpid). In order to allow debug to distinguish sdbth from other debugged user threads, the main core OS adds a / proc / lwpid / scoreid file, where lwpid is the thread number and scoreid is the file name. When creating sdbth, the corresponding scoreid file is created according to the requested slave core resources. If -1 is stored in the scoreid file, the thread specified by lwpid is another debugged user thread on the main core. If a non-negative integer is stored in the scoreid file, lwpid represents the slave core number, and the lwpid is sdbth.

[0069] When creating sdbth, the corresponding slave core number is stored in the scoreid file, and the data of the scoreid file of threads created elsewhere is initialized to -1, indicating the master core thread;

[0070] Before the debugger process debug executes the traditional attach process, a contract signal is sent to tracee. Tracee executes the interrupt processing function of the contract signal in the kernel runtime library. The interrupt processing function creates sdbth. Before debug executes the traditional detach process, sdbth is terminated.

[0071] These two situations ensure that whether you start debugging of a heterogeneous program in the debugging tool or debug a running heterogeneous program, you can debug the code running on the slave core through sdbth, which together with the debugging performed on the master core constitutes one-stop heterogeneous debugging;

[0072] Add a set of slave core architecture data and a switch in the debugger process debug;

[0073] From the core architecture data, this includes disassembly, reading and writing hardware registers, inserting and deleting hardware breakpoints, and calculating the address of the next instruction in the software single-step algorithm;

[0074] The switch is used to control the switching between the main core and the slave core processor architectures.

[0075] A heterogeneous multi-core software debugging method is also provided, based on the above heterogeneous multi-core software debugging device, characterized in that it includes the following steps:

[0076] S1. The debug process forks a child process, namely the tracee process, sets its debug flag TF, and establishes a control relationship between the debug process and the debugged process;

[0077] S2, the tracee process executes the debugged heterogeneous program and completes the slave core resource application and space initialization;

[0078] S3. When TF is true, the tracee process creates a debugging agent thread sdbth corresponding to each slave core and writes the slave core number in the scorid file;

[0079] S4. The Debug process captures the threads of the tracee process space one by one;

[0080] S5. The debug process finds the sdbth thread whose scorid is non-negative, and establishes a control relationship between sdbth and the corresponding slave core;

[0081] S6, Debug process initializes the architecture data for controlling slave core debugging;

[0082] S7, the debug process determines whether the breakpoint set by the user is the breakpoint of the master core or the slave core according to the address range of the slave core text segment;

[0083] S8. The debug process sets the main core breakpoint according to the main core architecture;

[0084] S9. The debug process sets slave core breakpoints according to the slave core architecture.

[0085] S10, the debug process resumes the tracee process;

[0086] S11, the tracee process runs to the slave core hardware breakpoint and sends a debug interrupt to the master core;

[0087] S12, the operating system processes the interrupt, sets the slave core debug interrupt flag, and sends a debug signal to the sdbth thread;

[0088] S13, the debug process is awakened by the debug signal of sdbth, the interrupt flag is determined, the master-slave core architecture data is switched, and the hardware architecture data structure is converted and switched to the slave core architecture data structure;

[0089] S14, the debug process converts the hardware scene into the corresponding slave core program scene. The specific conversion method is the same as the main core debugging;

[0090] S15. The Debug process exits and sdbth is terminated.

[0091] A heterogeneous multi-core software debugging method is also provided, based on the above heterogeneous multi-core software debugging device, characterized in that it includes the following steps:

[0092] S1. The debug process finds the process number of the running heterogeneous program;

[0093] S2. The debug process sends a specified signal to the running tracee process. The tracee process enters the interrupt processing function that executes the specified signal in the kernel runtime library. The interrupt processing function creates sdbth.

[0094] S3. The Debug process captures the threads of the tracee process space one by one;

[0095] S4. The debug process finds the sdbth thread whose scorid is non-negative, and establishes a control relationship between sdbth and the corresponding slave core;

[0096] S5, the debug process initializes the architecture data that controls the slave core debugging;

[0097] S6, the debug process determines whether the breakpoint set by the user is the breakpoint of the master core or the slave core according to the address range of the slave core text segment;

[0098] S7, Debug process sets the main core breakpoint according to the main core architecture;

[0099] S8. The debug process sets slave core breakpoints according to the slave core architecture;

[0100] S9, the debug process resumes the tracee process;

[0101] S10, the tracee process runs to the slave core hardware breakpoint and sends a debug interrupt to the master core;

[0102] S11, the operating system processes the interrupt, sets the slave core debug interrupt flag, and sends a debug signal to the sdbth thread;

[0103] S12, the Debug process is awakened by the debugging signal of sdbth, determines the interrupt flag, switches the master-slave core architecture data, and converts the hardware architecture data structure into the slave core architecture data structure;

[0104] S13, the debug process converts the hardware scene into the corresponding slave core program scene. The specific conversion method is the same as the main core debugging;

[0105] S14. The Debug process exits and sdbth is terminated.

[0106] The above embodiment is further explained as follows:

[0107] Due to the streamlined architecture design of the slave core, in order to support heterogeneous software debugging, the slave core hardware provides hardware breakpoint support and interrupts the main core OS when slave core breakpoints, slave core exceptions, slave core I / O requests, etc. occur.

[0108] It includes the creation mechanism of slave core proxy threads, the discrimination mechanism that is different from conventional Linux threads, that is, the discrimination mechanism of two processor architectures, and the switching mechanism for debugging multiple processor architectures.

[0109] The OS debugging interface of the master core is expanded to enable the traditional debugging interface to support the debugging of the slave core hardware thread;

[0110] A new control switch is added to gdb to support the switching of multiple processor architectures, thereby reusing open source code and supporting software debugging functions for heterogeneous multi-core processors;

[0111] It is necessary to add a small number of supporting modules to the Linux system, and reuse the Linux and gdb versions that are constantly updated by the open source community, so as to promote the open source debugging software to catch up with the development pace of heterogeneous many-core hardware and provide debugging tools for parallel computing applications based on heterogeneous many-core.

[0112] A slave core debugging proxy thread (sdbth) is proposed: sdbth is created by the main core OS, and sdbth runs in the address space of the traced process (tracee), cyclically executing a low-priority sleep. When the slave core issues an interrupt request to the main core, sdbth is awakened. After sdbth is awakened, it continues to execute the sleep system call in the OS kernel state and sends a debugging signal to itself. When returning from the kernel state to the user state, the OS checks and finds the debugging signal and the process tracking flag TF, and then wakes up the debugger process (debug).

[0113] In the existing design, debug should execute the system call Wait in a user-level loop at this time, waiting to be awakened by tracee. After debug is awakened, it obtains the execution control of the slave core program.

[0114] There are two opportunities to create Sdbth:

[0115] 1) run: When tracee is started by the run debugging command under debug control, the TF bit is set when the tracee process is created. When the application executes to the slave core parallel initialization, if TF is set, the slave core runtime library creates Sdbth after completing the slave core resource application and terminates sdbth after the slave core resources are released; otherwise, sdbth is not created.

[0116] 2) Attach: tracee is already running, and is executed after debug. The attach debug command is executed to apply for tracing and debugging of heterogeneous multi-cores. At this time, sdbth has not been created. Therefore, debug needs to add a design before executing the traditional attach process: send a specified signal (for example: 30) to tracee, tracee executes the interrupt processing function of signal 30 (in the slave core runtime library), and the interrupt processing function creates Sdbth. Debug terminates Sdbth before executing the traditional detach process.

[0117] A discrimination mechanism is needed: to determine whether a thread is from the kernel debugging agent sdbth or a normal Linux thread.

[0118] A simple design method is to add a / proc file, such as / proc / lwpid / scoreid, where lwpid is the thread number and scoreid is the file name. It is agreed that different data values ​​​​are stored in the scoreid file to distinguish whether the thread specified by lwpid is a normal Linux thread or sdbth.

[0119] When Sdbth is created, the corresponding slave core number is stored in the scoreid file; while for threads created elsewhere, the data in their scoreid files is initialized to -1, indicating the master core thread.

[0120] Through this design, the OS and debug can identify sdbth, thereby distinguishing the debugging of the master core and the slave core, and mapping the corresponding slave core hardware registers to the register buffer of sdbth, so that the debugger can convert the slave core hardware scene to the program scene.

[0121] The existing gdb version supports the design of multiple processor architectures in terms of code structure, but can only fix one processor architecture at runtime. Therefore, Debug needs to add two designs:

[0122] 1) A set of slave core architecture data, including disassembly, reading and writing of hardware registers, insertion and deletion of hardware breakpoints, and address calculation of the next instruction in the software single-step algorithm;

[0123] 2) A switch for controlling the switching between the master core and slave core processor architectures.

[0124] When Debug is initialized, it is initialized according to the processor architecture set during compilation. During compilation, only the main core architecture among the many cores can be set.

[0125] At runtime, Debug performs multi-thread debugging through thread switching. At each thread switch, the switch design is called to identify the thread scoreid file and switch the corresponding processor architecture.

[0126] If it is switched to Sdbth and the slave core architecture pointer is not initialized, the current processor architecture data pointer is saved to the master core architecture pointer, the slave core architecture initialization process is called again, the slave core architecture data initialization is executed, and the current architecture pointer is assigned as the slave core architecture pointer.

[0127] Through this pointer switching, debug switches between the two processor architectures, and the processing flow of various debugging commands calls the processing functions of the corresponding architecture when executing the architecture-related parts, thereby realizing program debugging for heterogeneous multi-cores.

[0128] When the heterogeneous multi-core software debugging device is used, it can realize execution tracking and error location of heterogeneous parallel codes, and can reuse the existing code architecture of the open source software gdb, which has good portability and feasibility.

[0129] In order to facilitate a better understanding of the present invention, the terms used in this article are briefly explained below:

[0130] Heterogeneous many-core processor: a low-power, high-performance processor architecture that integrates a small number of general-purpose main core processing units that perform management, communication and computing functions and a large number of streamlined slave core processing units (slave core array) that perform computing functions on a complete chip. The main core runs a general-purpose operating system (OS), mainly responsible for the management and control functions of the entire chip, and also undertakes certain computing functions and the chip's communication with the outside world; the slave core does not run the OS to reduce memory overhead, and fully exerts the function of accelerated computing.

[0131] Hardware thread: An operating unit determined by hardware technology and resources; different from traditional software threads. Software threads are scheduling units created by the OS to compete for processor resources, while hardware threads are not created and scheduled by the OS, or their address space is only managed by the OS.

[0132] Software breakpoint: A pseudo-instruction supported by hardware, with the shortest instruction length in the instruction system. It can replace an instruction of the debugged program. If a program exception occurs during runtime, it will then switch to executing the preset interrupt handler, transferring control of program execution to the user.

[0133] Hardware breakpoint: The processor performs instruction address matching during instruction fetching. The related hardware resource is the hardware breakpoint register, which stores the instruction address set by the user. When the instruction address in the register matches the data value of the program counter (PC), a debug interrupt occurs and the preset interrupt handler is executed. It can be seen that the number of hardware breakpoints is limited by the number of registers.

[0134] The above embodiments are only for illustrating the technical concept and features of the present invention, and their purpose is to enable people familiar with the technology to understand the content of the present invention and implement it accordingly, and they cannot be used to limit the protection scope of the present invention. Any equivalent changes or modifications made according to the spirit of the present invention should be included in the protection scope of the present invention.

Claims

1. A heterogeneous multi-core software debugging device, characterized in that: Includes the following configuration: From the core debug agent thread sdbth: sdbth is created by the main core OS, runs in the address space of the traced process tracee, and executes a low-priority sleep cycle; When the slave core issues an interrupt request to the master core, sdbth is woken up, wherein the interrupt request includes a debug interrupt request and an I / O request; After sdbth is awakened, it continues to execute the sleeping system call in the OS kernel state and sends a debugging signal to itself; When returning from kernel mode to user mode, OS checks for debug signals and finds the process trace flag TF, thus waking up the debugger process debug; After the debugger process debug is awakened, it obtains the execution control of the slave core program; If the interrupt request is an I / O request, the interrupt request is returned to the process tracee and processed according to the OS default method, that is, the processing process originally set for the I / O request is completed; If the interrupt request is a slave core debugging interrupt request, the breakpoint scene is analyzed and returned to the user to manually check the execution status of the slave core program stopped at the breakpoint; Add a set of slave core architecture data and a switch in the debugger process debug; From the core architecture data, this includes disassembly, reading and writing hardware registers, inserting and deleting hardware breakpoints, and calculating the address of the next instruction in the software single-step algorithm; The switch is used to control the switching between the main core and the slave core processor architecture.

2. The heterogeneous multi-core software debugging device according to claim 1, characterized in that: The creation timing of the slave core debugging agent thread sdbth includes the following two situations: When the application executes to the slave core parallel initialization, if the debugged flag TF is set, the slave core runtime library creates sdbth after completing the slave core resource application and terminates sdbth after the slave core resources are released. Otherwise, sdbth is not created. The main core OS adds a / proc / lwpid / scoreid file, where lwpid is the thread number and scoreid is the file name. When creating sdbth, the corresponding scoreid file is created according to the requested slave core resources. If -1 is stored in the scoreid file, the thread specified by lwpid is another debugged user thread on the main core. If a non-negative integer is stored in the scoreid file, lwpid indicates the slave core number, and the lwpid is sdbth. When creating sdbth, the corresponding slave core number is stored in the scoreid file, and the data of the scoreid file of threads created elsewhere is initialized to -1, indicating the master core thread; Before the debugger process debug executes the traditional attach process, a contract signal is sent to tracee. Tracee executes the interrupt processing function of the contract signal in the kernel runtime library. The interrupt processing function creates sdbth. Before debug executes the traditional detach process, sdbth is terminated.

3. A heterogeneous many-core software debugging method, based on the heterogeneous many-core software debugging device according to claim 1 or 2, characterized in that: The following steps are involved: S1. The debug process forks a child process, namely the tracee process, sets its debug flag TF, and establishes a control relationship between the debug process and the debugged process; S2, the tracee process executes the debugged heterogeneous program and completes the slave core resource application and space initialization; S3. When TF is true, the tracee process creates a debugging agent thread sdbth corresponding to each slave core and writes the slave core number in the scorid file; S4. The Debug process captures the threads of the tracee process space one by one; S5. The debug process finds the sdbth thread whose scorid is non-negative, and establishes a control relationship between sdbth and the corresponding slave core; S6, Debug process initializes the architecture data for controlling slave core debugging; S7, the debug process determines whether the breakpoint set by the user is the breakpoint of the master core or the slave core according to the address range of the slave core text segment; S8. The debug process sets the main core breakpoint according to the main core architecture; S9. The debug process sets slave core breakpoints according to the slave core architecture. S10, the debug process resumes the tracee process; S11, the tracee process runs to the slave core hardware breakpoint and sends a debug interrupt to the master core; S12, the operating system processes the interrupt, sets the slave core debug interrupt flag, and sends a debug signal to the sdbth thread; S13, the debug process is awakened by the debug signal of sdbth, the interrupt flag is determined, the master-slave core architecture data is switched, and the hardware architecture data structure is converted and switched to the slave core architecture data structure; S14, the debug process converts the hardware scene into the corresponding slave core program scene. The specific conversion method is the same as the main core debugging; S15. The Debug process exits and sdbth is terminated.

4. A heterogeneous many-core software debugging method, based on the heterogeneous many-core software debugging device according to claim 1 or 2, characterized in that: The following steps are involved: S1. The debug process finds the process number of the running heterogeneous program; S2. The debug process sends a specified signal to the running tracee process. The tracee process enters the interrupt processing function that executes the specified signal in the kernel runtime library. The interrupt processing function creates sdbth. S3. The Debug process captures the threads of the tracee process space one by one; S4. The debug process finds the sdbth thread whose scorid is non-negative, and establishes a control relationship between sdbth and the corresponding slave core; S5, the debug process initializes the architecture data that controls the slave core debugging; S6, the debug process determines whether the breakpoint set by the user is the breakpoint of the master core or the slave core according to the address range of the slave core text segment; S7, Debug process sets the main core breakpoint according to the main core architecture; S8. The debug process sets slave core breakpoints according to the slave core architecture; S9, the debug process resumes the tracee process; S10, the tracee process runs to the slave core hardware breakpoint and sends a debug interrupt to the master core; S11, the operating system processes the interrupt, sets the slave core debug interrupt flag, and sends a debug signal to the sdbth thread; S12, the Debug process is awakened by the debugging signal of sdbth, determines the interrupt flag, switches the master-slave core architecture data, and converts the hardware architecture data structure into the slave core architecture data structure; S13, the debug process converts the hardware scene into the corresponding slave core program scene. The specific conversion method is the same as the main core debugging; S14. The Debug process exits and sdbth is terminated.

Images