CN115221053B

CN115221053B - DSP debugging framework based on Ethernet

Info

Publication number: CN115221053B
Application number: CN202210837666.7A
Authority: CN
Inventors: 傅昊
Original assignee: Chengdu Chuanshan Yunjia Technology Co ltd
Current assignee: Chengdu Chuanshan Yunjia Technology Co ltd
Priority date: 2022-07-15
Filing date: 2022-07-15
Publication date: 2023-03-24
Anticipated expiration: 2042-07-15
Also published as: CN115221053A

Abstract

The invention relates to the technical field of DSP debugging, and discloses a DSP debugging framework based on an Ethernet, namely, the DSP debugging framework comprises a debugging host and a DSP target machine which are connected through Ethernet communication, wherein a debugging client program runs on the debugging host, a debugged program runs on the DSP target machine, the debugged program comprises a debugging service terminal program compiled in a library file form, and debugging functions such as uploading and displaying of breakpoint abnormal reported information and issuing and executing of debugging commands can be realized through information interaction after communication connection is established between the debugging client program and the debugging service terminal program.

Description

DSP debugging framework based on Ethernet

Technical Field

The invention belongs to the technical field of DSP debugging, and particularly relates to a DSP debugging framework based on Ethernet.

Background

Digital Signal Processors (DSPs) have been widely used in voice, communication, image processing and other fields and play an important role because of their advantages of flexibility, stability, large-scale integration and easy real-time implementation.

Currently, software developers use an integrated environment (e.g., CCS, which is known as CodeComposer Studio, and is a code development and debugging suite produced by texas instruments, usa) provided by DSP manufacturers as a DSP software debugging environment, need to equip a manufacturer-specific emulator, have high cost, generally only support a Windows operating system as a debugging host, and have core technologies held in the hands of a few DSP manufacturers. In addition, the special emulator is limited by the length of the transmission line (usually only about 1.5 meters), and one emulator can only be connected with one DSP processor, and cannot adapt to the scene of remote debugging or the connection of one debugging host computer with a plurality of DSP target machines.

Due to the above problems, especially the national requirements for autonomous and controllable security of software and hardware of the basic software system are continuously increased, so that the demand for embedded remote debugging software for the DSP platform becomes stronger and stronger.

Disclosure of Invention

In order to solve the problem that the existing DSP software debugging scheme has a lot of limitations due to the need of an emulator, the invention aims to provide a DSP debugging framework based on the Ethernet, which can be used for realizing the purposes of remotely debugging a DSP target machine and connecting and debugging a plurality of DSP target machines by using a debugging host without an emulator, simultaneously reducing the debugging cost, meeting the national requirements on the software and hardware safety autonomous controllable technology of a basic software system and embedded remote debugging software facing a DSP platform, and being convenient for practical application and popularization.

The invention provides an Ethernet-based DSP debugging framework, which comprises a debugging host and a DSP target machine which are connected through Ethernet communication, wherein the debugging host runs a debugging client program, the DSP target machine runs a debugged program, and the debugged program comprises a debugging service terminal program compiled in a library file form;

the debugging client program is used for receiving and displaying breakpoint abnormal reporting information from the debugging service terminal program on one hand and transmitting a debugging command input by a user to the debugging service terminal program on the other hand after establishing communication connection with the debugging service terminal program, wherein the debugging command is a single step execution command or a running recovery command;

the debugging service terminal program is used for generating an unmasked interrupt when the debugged program executes the illegal instruction by inserting the illegal instruction into the debugged program, acquiring a processor control right when the unmasked interrupt occurs, then storing the context of the debugged program when the unmasked interrupt occurs, transmitting the breakpoint exception report information to the debugging client program, inserting the next illegal instruction into the debugged program according to the debugging command after receiving the debugging command, then recovering the context of the debugged program, and returning the processor control right to the debugged program to enable the debugged program to continue to operate at a pause position.

Based on the content of the invention, a new DSP software debugging scheme without an emulator is provided, namely the new DSP software debugging scheme comprises a debugging host and a DSP target machine which are connected through Ethernet communication, wherein a debugging client program runs on the debugging host, a debugged program runs on the DSP target machine, the debugged program comprises a debugging service terminal program compiled in a library file form, and information interaction is carried out after communication connection is established between the debugging client program and the debugging service terminal program, so that uploading and display of breakpoint abnormal report information and issuing and executing of debugging commands and other debugging functions can be realized.

In a possible design, when the non-maskable interrupt occurs, obtaining a processor control right, then saving a context of the debuggee program when the non-maskable interrupt occurs, transmitting the breakpoint exception report information to the debugging client program, and after receiving the debugging command, inserting a next illegal instruction into the debuggee program according to the debugging command, then recovering the context of the debuggee program, and returning the processor control right to the debuggee program to enable the debuggee program to continue to run at a pause, including the following steps S21 to S29:

s21, when the unmasked interrupt occurs, triggering to acquire the control right of the processor, and then executing the step S22;

s22, saving the context of the debugged program, restoring the illegal instruction at the preset breakpoint into a first legal instruction stored in a first register due to the fact that the breakpoint is set in advance, and then executing the step S23;

s23, judging whether the first legal instruction is a 16-bit simplified instruction or a 32-bit instruction, if the first legal instruction is the 16-bit simplified instruction, reading a PC value in an instruction counter, taking a new PC value as a current address after the PC value is subtracted by 2, and then executing the step S24, and if the first legal instruction is the 32-bit instruction, reading the PC value in the instruction counter, taking the PC value as the current address, and then executing the step S24, wherein the instruction counter is used for storing the address of the current instruction to be executed by the debugged program, and the current address refers to the address of the first instruction executed by the debugged program after the debugged program resumes operation;

s24, transmitting the first breakpoint abnormity report information carrying the context and the current address to the debugging client program, and then executing the step S25;

s25, waiting for a debugging command from the debugging client program, and executing the step S26 after receiving the debugging command which is a single step execution command;

s26, analyzing to obtain a next instruction address according to an instruction coding rule and a parallel instruction judgment algorithm, and then executing a step S27, wherein the next instruction address refers to the address of a next non-parallel instruction after the first instruction;

s27, taking the next instruction address as a new preset breakpoint, storing a second legal instruction at the next instruction address in the first register, and then executing the step S28;

s28, judging whether the second legal instruction is a 16-bit simplified instruction or a 32-bit instruction, if the second legal instruction is the 16-bit simplified instruction, replacing the second legal instruction at the next instruction address with a 16-bit illegal instruction, and then executing the step S29, and if the second legal instruction is the 32-bit instruction, replacing the second legal instruction at the next instruction address with a 32-bit illegal instruction, and then executing the step S29;

and S29, restoring the context of the debuggee program, returning the processor control right to the debuggee program so as to restore the operation of the debuggee program, and then returning to execute the step S21.

In one possible design, if the instruction is a 16-bit simplified instruction, the second legal instruction at the next instruction address is replaced by a 16-bit illegal instruction, and then step S29 is performed, which includes:

when it is determined that the second legal instruction is a 16-bit simplified instruction, the second legal instruction at the next instruction address is replaced with a 16-bit illegal instruction, the instruction of the packet header of the instruction fetch packet where the second legal instruction is located is replaced with the 16-bit illegal instruction, the parallel flag bit of the instruction is invalidated, and then step S29 is performed.

In one possible design, in step S25, if a debug command is received as the resume run command, step S29 is directly executed, and if a debug command is received as another command, the other command is executed and responded, and then step S25 is executed again, where the other command refers to a command that is not the single-stepping command and a command that is not the resume run command.

In one possible design, the debugging client program is further configured to, in a StepOver type single step debugging process, control the debuggee program to skip calling an API function on the DSP target side according to the following steps:

receiving second breakpoint exception reporting information which comes from the debugging service terminal program and carries a current address, wherein the second breakpoint exception reporting information triggers the debugging service terminal program to generate and transmit when the debugged program encounters a preset breakpoint after executing one-step debugging, and the current address refers to an address of a first instruction executed after the debugged program resumes running;

judging whether the instruction operation code at the current address indicates a call instruction or not;

if so, extracting and obtaining an initial address of the API function called by the call instruction according to the call instruction;

extracting an operation code of a first instruction of the API function from the initial address of the API function;

calculating the address of a prefetch instruction header fphead according to the operation code of the first instruction of the API function, and extracting another instruction operation code from the address of the prefetch instruction header fphead;

determining whether the other instruction opcode indicates an fphead instruction or is within the jurisdiction of an fphead instruction;

and if so, taking the next non-parallel instruction address behind the current address as an address to be interrupted, and returning a single-step execution command carrying the address to be interrupted to the debugging service terminal program, so that the debugging service terminal program carries out next debugging after taking the address to be interrupted as a new preset breakpoint.

In one possible design, the debugging client program is further configured to, in a StepOver type single step debugging process, control the debuggee program to skip calling a third-party library function according to the following steps:

judging whether the instruction operation code at the current address indicates a B instruction for executing the unconditional jump to a third-party library function;

if yes, extracting a target address located in a target address register according to the instruction B, wherein the target address register is used for recording an initial address of the third-party library function;

extracting an operation code of a first instruction of the library function from the target address;

calculating the address of a prefetch instruction header fphead according to the operation code of the first instruction of the library function, and extracting another instruction operation code from the address of the prefetch instruction header fphead;

In one possible design, the debugging service terminal program is further configured to, when the DSP target machine adopts a multi-core DSP chip and runs on a designated master core, take each of the other cores as a slave core, and create at least one communication proxy task on the master core, where the master core and each of the slave cores run the debugged program and the debugging service terminal program independently, the at least one communication proxy task corresponds to at least one slave core one to one, and each of the at least one communication proxy task is used to monitor a different port number and represent a debugging service terminal program corresponding to a slave core to communicate with the debugging client program;

the working steps of each communication agent task comprise:

after receiving an interrupt point command which is issued by the debugging client program and used for setting a breakpoint corresponding to a debugging service terminal program of a slave core, storing the interrupt point command and marking the interrupt point command, and then uploading response information to the debugging client program;

after receiving a debugging command which is issued by the debugging client program and used for indicating a corresponding slave core to continuously run a debuggee program, transmitting the debugging command and the breakpoint command to a debugging service terminal program of the corresponding slave core, and clearing the mark so as to inform the debugging service terminal program of the corresponding slave core to exit a waiting state, and continuously running the debuggee program after setting a breakpoint according to the breakpoint command;

entering a waiting state after clearing the mark until exiting the waiting state when the corresponding debugged program running on the slave core generates an unmasked interrupt and makes the debugging service terminal program of the corresponding slave core enter the waiting state again;

and after the waiting state is exited, uploading third breakpoint exception reporting information which comes from the debugging service terminal program of the corresponding slave core and is used for reporting that the debuggee program running on the corresponding slave core generates the unmasked interrupt to the debugging client program.

In one possible design, the debugging service terminal program is further configured to respectively refresh caches of the first core and the second core when the first core accesses the memory of the second core across cores using a global address corresponding to the second core, where the first core and the second core belong to the multi-core DSP chip, and the caches include an instruction cache and a data cache.

In one possible design, the debugging client program is further configured to create a thread for receiving and displaying text data from the DSP target machine at startup, where the thread is configured to create a first Socket based on a UDP protocol and bind a port number of the DSP target machine;

the debugging service terminal program is further configured to, when the debugging client program is connected to the master core, acquire an IP address of the debugging host, maintain the IP address as a target address of a text output function eprintf, and simultaneously create a text output communication proxy task and a second Socket based on a UDP protocol and used for communicating with the first Socket, where the text output function eprintf is used to mark the master core/slave core that sends text data while outputting text data;

the debugged program is configured to directly use the second Socket to send text data to the debugging client program when the text output function eprint is called on the master core, and set a text buffer address of text data to be sent in a second register corresponding to the slave core and enable a text output flag to be valid when the text output function eprint is called on the slave core CPU, so that when the text output communication agent task finds that the text output flag corresponding to the slave core is valid through polling, the text data to be sent in the text buffer is obtained according to the text buffer address corresponding to the slave core, and the text data to be sent is sent to the debugging client program by using the second Socket.

In one possible design, the debug client program establishes a communication connection with the debug service terminal program through a remote serial communication protocol RSP.

The beneficial effects of the invention contents are as follows:

(1) The invention has created and provided a new scheme of DSP software debugging without simulator, namely include debugging host computer and DSP target machine that link up through Ethernet communication, wherein, debug the host computer and run and debug the customer end procedure, the said DSP target machine runs and has debugged the procedure, include the debug service terminal program compiled in the form of library file in the said debugged procedure, and through the information interaction after establishing communication connection with said debug service terminal program of said debug customer end procedure, can realize uploading and display of the abnormal report information of breakpoint and debugging the order and debugging the debug the function such as being issued and carried out, etc., so need simulator can carry on-line debugging too, and realize the purpose of debugging the target machine and connecting and debugging a plurality of DSP target machines with a debugging host computer remotely, reduce the debug cost at the same time, meet the national demand to basic software system software and hardware safe autonomous controllable technology and embedded remote debugging software facing DSP platform;

(2) In the StepOver type single step debugging process, the debugged program can perfectly skip and call the API function of the DSP target machine side, so that the condition that the DSP target machine loses response due to the fact that a temporary breakpoint is beaten in the called function can be avoided, and a debugging host can be ensured to continue subsequent debugging;

(3) In the StepOver type single step debugging process, the debugged program can perfectly skip and call a third-party library function, so that the single step debugging progress can be accelerated, the debugging failure probability caused by the encounter of 16-bit simplified instructions is reduced, and the debugging host can be ensured to continue subsequent debugging;

(4) The multi-core concurrent debugging process can be simplified through the establishment of communication agent tasks and the working mode thereof, so that the multi-core concurrent debugging process is easy to control and feasible, and due to no introduction of a competition mechanism, the exception of the whole system can be avoided, and the problem of unpredictable program execution caused by the inconsistency of a memory and a cache can also be avoided;

(5) The function of outputting text data through the Ethernet can be realized in the multi-core concurrent debugging process, and the applicability of a debugging framework is ensured.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

Fig. 1 is a schematic structural diagram of an ethernet-based DSP debugging architecture provided in the present invention.

Fig. 2 is a schematic flow chart of cross debugging performed by the DSP debugging architecture provided by the present invention.

Fig. 3 is a schematic diagram of an application of the present invention for connecting and debugging a plurality of DSP target machines by using a debugging host.

Fig. 4 is a schematic operation flow diagram of the debugging service terminal program provided by the present invention.

Fig. 5 is a schematic flow chart of the debugging client program controlling the debuggee program to skip calling the API function on the DSP target machine side in the StepOver type single step debugging process provided by the present invention.

Fig. 6 is a schematic flow chart of the debugging client program controlling the debuggee program to skip the call of the third-party library function in the StepOver type single-step debugging process provided by the present invention.

Fig. 7 is a schematic diagram of an application of the DSP debugging architecture provided by the present invention to perform multi-core concurrent debugging.

Fig. 8 is a schematic flow chart of performing multi-core concurrent debugging by using the DSP debugging architecture provided in the present invention.

FIG. 9 is a flowchart illustrating the output of text data by the DSP debugging architecture according to the present invention.

Detailed Description

The invention is further described with reference to the following figures and specific embodiments. It should be noted that the description of the embodiments is provided to help understanding of the present invention, but the present invention is not limited thereto. Specific structural and functional details disclosed herein are merely representative of exemplary embodiments of the invention. This invention may, however, be embodied in many alternate forms and should not be construed as limited to the embodiments set forth herein.

It will be understood that, although the terms first, second, etc. may be used herein to describe various objects, these objects should not be limited by these terms. These terms are only used to distinguish one object from another. For example, a first object may be referred to as a second object, and similarly, a second object may be referred to as a first object, without departing from the scope of example embodiments of the present invention.

It should be understood that, for the term "and/or" as may appear herein, it is merely an associative relationship that describes an associated object, meaning that three relationships may exist, e.g., a and/or B may mean: a exists alone, B exists alone or A and B exist at the same time; for the term "/and" as may appear herein, which describes another associative object relationship, it means that two relationships may exist, e.g., a/and B, may mean: a exists singly or A and B exist simultaneously; in addition, for the character "/" that may appear herein, it generally means that the former and latter associated objects are in an "or" relationship.

Example one

As shown in fig. 1 to 4, the DSP debugging architecture based on ethernet provided in this embodiment includes a debugging host and a DSP target connected by ethernet communication, where the debugging host runs a debugging client program, the DSP target runs a debugged program, and the debugged program includes a debugging service terminal program compiled in a library file form; the debugging client program is used for receiving and displaying breakpoint abnormal reporting information from the debugging service terminal program on one hand and transmitting a debugging command input by a user to the debugging service terminal program on the other hand after establishing communication connection with the debugging service terminal program, wherein the debugging command is a single step execution command or a running recovery command; the debugging service terminal program is used for enabling the debugged program to generate Non-Maskable interruption (Non-masable Interrupt, NMI) when the illegal instruction is executed, acquiring a processor control right when the Non-Maskable interruption occurs, then saving the context of the debugged program when the Non-Maskable interruption occurs, transmitting breakpoint exception report information to the debugging client program, inserting the next illegal instruction into the debugged program according to the debugging command after the debugging command is received, then recovering the context of the debugged program, and returning the processor control right to the debugged program to enable the debugged program to continue running at a pause position.

As shown in fig. 1, in the specific structure of the DSP debugging architecture, the debugging host is configured to provide a DSP software debugging function for a user (i.e., a debugging person), so as to implement functions of inputting and sending a debugging command, analyzing and displaying debugging response data (including but not limited to the breakpoint exception report information, etc.). The debugging client program is preferably developed based on an open source GDB (GNUDebugger abbreviation, which is a powerful program debugging tool under UNIX issued by GNU open source organization), at this time, if the operating system of the debugging host is a Windows system, a GDB operating environment Cygwin needs to be provided in the debugging host (namely, since the GDB executable program is an ELF format file, the GDB executable program cannot be directly executed on the Windows operating system, the Cygwin operating environment is needed), and if the debugging host is a Linux host, the Cygwin operating environment is not needed). In order to enable the user to install different modules according to different needs, specifically, the debugging client program includes, but is not limited to, a user interface module, a debugging function module, a client communication module, an operating system support module, and the like, wherein the client communication module preferably employs a communication module based on a remote serial communication Protocol RSP (remote serial Protocol, an existing ASCII code character stream Protocol based on messages), so that the debugging client program establishes a communication connection with the debugging service terminal program through the remote serial communication Protocol RSP. In addition, as shown in fig. 2, after the debugging client program is started and before the connection is established, the image file of the debugged program needs to be loaded, so as to perform subsequent online debugging; and the reference configuration of the debugging host can be exemplified as follows: the processors are Intel I5 and above; the size of the memory is more than or equal to 8GB; the size of the hard disk is more than or equal to 500GB; the network port is 1 or more than one gigabit Ethernet.

The DSP target machine is target equipment to be subjected to software debugging aiming at the debugged program. The debugging service terminal program is used as an intermediary between the debugging client program and the debugged program and provides a bottom layer support for realizing debugging functions for the debugging client program, wherein the debugging functions include but are not limited to functions of data transmission, debugging command execution (specifically including but not limited to accessing or modifying a DSP register, accessing and modifying a target machine memory, setting or deleting breakpoints, single step, stack backtracking or debugged program operation recovery and the like), application program state acquisition and control and the like. Since the SYS/BIOS operating system on the DSP target machine does not have a process concept similar to that on the Windows/Linux system, the debug service terminal program cannot be run as an independent task (process) alone, and needs to be compiled into the debuggee program in the form of a library file (. Lib). In order to enable the user to install different modules according to different needs, specifically, the debugging service terminal program includes, but is not limited to, a debugging command execution module, a service communication module, a code control module, and the like, wherein the service communication module preferably adopts a communication module based on the remote serial communication protocol RSP as well. In addition, as shown in fig. 2, the debugging service terminal program needs to initialize before the debuggee program is interrupted due to abnormal operation, and initialize a breakpoint exception vector table, so as to perform online debugging in the following; and the reference configuration of the DSP target machine may be, for example: the model of the DSP chip is TMS320C6678; the dominant frequency is 1GHz; the operation mode is 32 bits; DDR3 specification: the size is more than or equal to 4GB, and the bit width is 64bit; FLASH specification: bit width 16bit, capacity 2Gbit; ethernet exchange chip: the SPI interface for the configuration of the switching chip is connected to the FPGA3, and the switching chip can be configured through the MCU after being electrified; and as shown in fig. 3, in order to improve the debugging efficiency, a debugging host can be used to connect and debug a plurality of DSP target machines through an ethernet switch.

As shown in fig. 4, specifically, when the non-maskable interrupt occurs, obtaining a processor control right, then saving a context of the debuggee program when the non-maskable interrupt occurs, transmitting breakpoint exception report information to the debugging client program, after receiving the debugging command, inserting a next illegal instruction into the debuggee program according to the debugging command, then restoring the context of the debuggee program, and returning the processor control right to the debuggee program, so that the debuggee program continues to run at a suspended position, including but not limited to the following steps S21 to S29.

And S21, when the unmasked interrupt occurs, triggering to acquire the control right of the processor, and then executing the step S22.

S22, saving the context of the debuggee program, restoring the illegal instruction at the preset breakpoint into a first legal instruction stored in a first register due to the previous set breakpoint, and then executing step S23.

Before step S21, the first legal instruction is temporarily stored in the first register due to a preset breakpoint, and at this time, a 16/32-bit illegal instruction is located at an original instruction address of the first legal instruction, so as to form a preset breakpoint, and an unmasked interrupt is triggered when the debuggee program runs the 16/32-bit illegal instruction.

And S23, judging whether the first legal instruction is a 16-bit simplified instruction or a 32-bit instruction, if so, reading a PC (Program Counter) value in an instruction Counter, taking a new PC value as a current address after the PC value is reduced by 2, and then executing the step S24, and if so, reading the PC value in the instruction Counter, taking the PC value as the current address, and then executing the step S24, wherein the instruction Counter is used for storing the address of the current instruction to be executed by the debugged Program, and the current address refers to the address of the first instruction executed by the debugged Program after the debugged Program resumes operation.

And S24, transmitting the first breakpoint abnormity report information carrying the context and the current address to the debugging client program, and then executing the step S25.

In step S24, the sending timing of the first breakpoint abnormal report information may be performed after the communication connection between the debugging client program and the debugging service terminal program is established, and then wait for a debugging command from the debugging client program.

S25, waiting for the debugging command from the debugging client program, and executing the step S26 after receiving the debugging command which is a single step execution command.

S26, analyzing to obtain a next instruction address according to the instruction coding rule and the parallel instruction judgment algorithm, and then executing the step S27, wherein the next instruction address refers to the address of the next non-parallel instruction after the first instruction.

In step S26, the specific analysis method is the conventional method.

And S27, taking the next instruction address as a new preset breakpoint, storing a second legal instruction at the next instruction address in the first register, and then executing the step S28.

S28, judging whether the second legal instruction is a 16-bit simplified instruction or a 32-bit instruction, if so, replacing the second legal instruction at the next instruction address with a 16-bit illegal instruction, and then executing the step S29, and if so, replacing the second legal instruction at the next instruction address with a 32-bit illegal instruction, and then executing the step S29.

In step S28, specifically, if the instruction is a 16-bit simplified instruction, the second legal instruction at the next instruction address is replaced by a 16-bit illegal instruction, and then step S29 is executed, which includes but is not limited to: when it is determined that the second legal instruction is a 16-bit simplified instruction, the second legal instruction at the next instruction address is replaced with a 16-bit illegal instruction, the instruction of the packet header of the instruction fetch packet where the second legal instruction is located is replaced with the 16-bit illegal instruction, the parallel flag bit of the instruction is invalidated, and then step S29 is performed. In detail, the specific way of invalidating the parallel flag bit may be, but is not limited to, setting the parallel flag bit to "0" (i.e. clearing), so as to ensure that the instruction in the packet header of the instruction fetch packet where the second legal instruction is located is not executed in parallel with the next instruction.

The foregoing steps S21 to S29 provide a detailed scheme for performing breakpoint breaking and single step debugging in a loop manner, so as to debug the debugged program step by step. In addition, in the step S25, if the debug command is the resume operation command, the step S29 is directly executed, and if the debug command is the other command, which is the non-single step execution command and the non-resume operation command, is received, the other command is executed and responded, and then the step S25 is returned to be executed.

Therefore, based on the detailed description of the DSP debugging framework, a novel DSP software debugging scheme without an emulator is provided, namely the novel DSP software debugging scheme comprises a debugging host and a DSP target machine which are connected through Ethernet communication, wherein a debugging client program runs on the debugging host, a debugged program runs on the DSP target machine, the debugged program comprises a debugging service terminal program compiled in a library file form, and debugging functions such as uploading and displaying of breakpoint abnormal report information and issuing and execution of debugging commands can be realized through information interaction of the debugging client program and the debugging service terminal program after communication connection is established.

On the basis of the technical solution of the first aspect, this embodiment further provides a possible design how to control the debuggee program to skip calling the API function on the DSP target side — that is, since the function in the debuggee program is inevitably called in the debugging process, for a StepOver type single-step debugging manner (that is, during single-step execution, when a sub-function is encountered in the function, the single-step execution in the sub-function is not performed, but the whole execution of the sub-function is stopped, that is, the whole execution of the sub-function is regarded as one step), the existing common processing method is: a temporary breakpoint is marked at a first instruction for calling an API function at the side of a DSP target machine in advance, when a debugged program runs to the instruction, the temporary breakpoint is suspended, and then a signal of encountering the breakpoint is reported to a debugging host machine through the DSP target machine; the debugging host analyzes that the current function is in the called function by looking up the symbol table of the debuggee program, and should not further step in the function, so that a temporary breakpoint is made at the next instruction of the instruction calling the function.

Examples are as follows:

when performing StepOver type single step debugging, the debugging host informs the DSP target machine to make a temporary breakpoint at the entry address 0x81013d9c of the function mymulf, and after the debuggee program runs and encounters the breakpoint, the debugging host makes a temporary breakpoint at the next instruction address 0x81013e9c (note: because the call instruction calling the mymulf function is a parallel instruction with the next ldw instruction, the debugging host does not make a temporary breakpoint at the instruction address). However, the address 0x81013e9c is a call instruction, which calls the system function _ remi provided by the SYS/BIOS system on the DSP target side to perform the "remainder" operation, and at this time, if the single step debugging is continuously performed, the debugging host will first notify the DSP target machine to make a temporary breakpoint at the entry address of the system function _ remi, which may cause an internal exception of the unmasked Interrupt NMI (Non Maskable Interrupt) reported by the SYS/BIOS system, causing the DSP target machine to lose response, and further causing the debugging host to be unable to continuously perform the subsequent debugging.

In detail, the internal implementation of the system function _ remi can be seen by disassembling:

from the instruction composition, the code comprises a 16-bit compact instruction (compact) and a normal 32-bit instruction, and also comprises a parallel instruction mixed by the 16-bit compact instruction and the 32-bit instruction.

In summary, in order to avoid the situation that the DSP target machine loses response due to the fact that the API function on the DSP target machine needs to be called in the StepOver type single step debugging process, as shown in fig. 5, the debugging client program is further configured to control the debuggee program to skip the API function on the DSP target machine side according to the following steps S31 to S37 in the StepOver type single step debugging process.

And S31, receiving second breakpoint exception reporting information which comes from the debugging service terminal program and carries a current address, wherein the second breakpoint exception reporting information is generated and transmitted by triggering the debugging service terminal program when the debuggee program encounters a preset breakpoint after executing one-step debugging, and the current address refers to an address of a first instruction executed after the debuggee program resumes running.

In the step S31, the generating and transmitting manner of the second breakpoint exception report information may refer to the foregoing steps S21 to S23, which are not described herein again.

And S32, judging whether the instruction operation code at the current address indicates a call instruction.

In the step S32, taking the call of the system function _ remi as an example, if the current address is 0x81013e9c, the corresponding instruction opcode is 0x108d5813, which just indicates a call instruction.

And S33, if so, extracting and obtaining the initial address of the API function called by the call instruction according to the call instruction.

After the step S32, if it is determined that the instruction operation code at the current address does not indicate a call instruction, it indicates that the API function of the DSP target machine side is not currently called, and may return a resume operation command carrying the current address to the debugging service terminal program, so that the debugged program performs next debugging at the current address.

And S34, extracting the operation code of the first instruction of the API function from the initial address of the API function.

In the step S34, also taking the example of calling the system function _ remi, the start address is 0x8105a940, and the corresponding opcode is 0x0093e9a1.

S35, calculating the address of the prefetch instruction header fphead according to the operation code of the first instruction of the API function, and extracting another instruction operation code from the address of the prefetch instruction header fphead.

In the step S35, a specific calculation method is an existing algorithm, and also taking a system function _ remi as an example, the address of the prefetch instruction header fphead is 0x8105a95c, and the corresponding another instruction opcode is 0xe0800030.

S36, judging whether the other instruction operation code indicates an fphead instruction or is in the jurisdiction range of the fphead instruction.

In step S36, since each fphead instruction dominates 7 32-bit instructions (where, if there is a 16-bit reduced instruction, each two 16-bit reduced instructions will be regarded as 1 32-bit instruction), it is necessary to determine whether the other instruction opcode indicates an fphead instruction, and also determine whether the indicated instruction is in the scope of the command of an fphead instruction. Also taking the example of calling the system function _ remi, (0xe0800030 &0xf0000000) =0xe0000000, the instruction indicated by the other instruction opcode 0xe0800030 is in one fphead instruction jurisdiction.

And S37, if so, taking the next non-parallel instruction address behind the current address as an address to be interrupted, and returning a single-step execution command carrying the address to be interrupted to the debugging service terminal program, so that the debugging service terminal program carries out next debugging after taking the address to be interrupted as a new preset breakpoint.

In step S37, if yes, it indicates that one of two conditions (i.e., the other instruction opcode indicates an fphead instruction and the instruction indicated by the other instruction opcode is within the scope of an fphead instruction) is satisfied. Also for example, calling the system function _ remi, the address to be interrupted will be set to 0x81013e9c +12=0x81013ea8, and since the two subsequent instructions in the call instruction are parallel instructions, 12 bytes are added for the purpose of skipping.

Therefore, based on the detailed description of the possible design one, the debugged program can perfectly skip and call the API function of the DSP target machine side in the StepOver type single step debugging process, so that the condition that the DSP target machine loses response due to the fact that a temporary breakpoint is hit in the called function can be avoided, and the debugging host can be ensured to continue subsequent debugging.

In this embodiment, on the basis of the technical solution of the first aspect, a second possible design is provided for how to control the debuggee program to skip the call of the third-party library function, that is, when the debuggee program calls the third-party library function, particularly when the third-party library function is called in a function pointer form, the call is performed not by the function call instruction callp but by unconditionally jumping to the target function through the B instruction, and the target function often contains a 16-bit reduced instruction, and if the debugging host continues to perform single-step debugging in the target function, it is not necessary, and it may also cause a debugging failure due to the occurrence of the 16-bit reduced instruction, and therefore when the third-party library function is called by the B instruction, it is necessary to skip the instruction.

Examples of such cases are as follows:

/>

an example of compiler-generated assembly instructions and machine code is as follows, where it can be seen that the call to the third party library function is done by a direct jump of the B instruction.

An example of the assembler instructions and machine code of the third-party library function generated by the compiler is as follows, and it can be seen that the third-party library function has both 16-bit simplified instructions and parallel instructions mixed therein.

As can be seen from the assembly instruction, the debugging host skips the third-party library function called in the B instruction unconditional jump mode, and needs to first determine according to the B instruction unconditional machine code characteristic value 0x360, and if such an instruction is the case, it can be determined according to the possible design two of this embodiment whether the B instruction needs to be skipped, that is, as shown in fig. 6, the debugging client program is further configured to control the debuggee program to skip the third-party library function in the StepOver type single-step debugging process according to the following steps S41 to S47.

S41, second breakpoint abnormity reporting information which comes from the debugging service terminal program and carries a current address is received, wherein the second breakpoint abnormity reporting information is generated and transmitted by triggering the debugging service terminal program through a preset breakpoint encountered by the debugged program after each step of debugging is executed, and the current address refers to an address of a first instruction executed after the debugged program resumes running.

S42, judging whether the instruction operation code at the current address indicates a B instruction for executing the unconditional jump to the third-party library function.

And S43, if so, extracting and obtaining a target address positioned in a target address register according to the instruction B, wherein the target address register is used for recording the initial address of the third-party library function.

And S44, extracting the operation code of the first instruction of the library function from the target address.

S45, calculating the address of the prefetch instruction header fphead according to the operation code of the first instruction of the library function, and extracting another instruction operation code from the address of the prefetch instruction header fphead.

S46, judging whether the other instruction operation code indicates an fphead instruction or is in the jurisdiction range of the fphead instruction.

And S47, if yes, taking the next non-parallel instruction address behind the current address as an address to be interrupted, and returning a single-step execution command carrying the address to be interrupted to the debugging service terminal program, so that the debugging service terminal program can carry out next debugging after taking the address to be interrupted as a new preset breakpoint.

The technical details of the foregoing steps S41 to S47 can be derived from the foregoing possible designs, and are not described herein again.

Therefore, based on the specific content of the possible design two, the debugged program can perfectly skip and call a third-party library function in the StepOver type single step debugging process, so that the single step debugging progress can be accelerated, the debugging failure probability caused by encountering a 16-bit simplified instruction is reduced, and the debugging host can be ensured to continue subsequent debugging.

The present embodiment provides a third possible design of how to perform multi-core concurrent debugging based on the technical solution of the first aspect, that is, because a single DSP chip, such as the model TMS320C6678, may adopt a KeyStone multi-core processor architecture, if an inter-core communication mechanism of the DSP chip is utilized, although multi-core concurrent debugging may be implemented, an inter-core interrupt mechanism is required in a communication process thereof, which is relatively complex to use and is not easy to Control, and if network communication is performed in a manner of sharing an ethernet driver and a TCP/IP (Transmission Control Protocol/Internet Protocol) Protocol stack among the core processors, contention of each core processor on the driver and the Protocol stack may cause an abnormality of the entire system.

For the problem of the multi-core concurrent debugging, a specific solution provided by this embodiment, which may be designed three, is: the debugging service terminal program is further configured to, when the DSP target machine adopts a multi-core DSP chip and runs on a specified master core (e.g., core 0), take other cores (e.g., core1 to core 7) as slave cores, respectively, and create at least one communication proxy task on the master core, where the master core and each slave core run the debugged program and the debugging service terminal program independently, the at least one communication proxy task corresponds to at least one slave core one to one, and each communication proxy task in the at least one communication proxy task is used to monitor a different port number and represents a debugging service terminal program corresponding to a slave core to communicate with the debugging client program.

As shown in fig. 7, for example, when the multi-Core DSP chip has eight cores, if the eight cores are respectively denoted as Core0, core1, core2, core3, core4, core5, core6, and Core7, then Core0 may be designated as the master Core, and Core1, core2, core3, core4, core5, core6, and Core7 may be respectively designated as the slave cores, so that 7 communication agent tasks task1 to task7 need to be created in a one-to-one correspondence for 7 slave cores.

As shown in fig. 8, after the debug connection is established, the working steps of the tasks of the communication agents include, but are not limited to, the following steps S51 to S54.

And S51, after receiving an interruption point command which is issued by the debugging client program and is used for setting a breakpoint corresponding to the debugging service terminal program from the kernel, storing the interruption point command, marking the interruption point command, and then uploading response information to the debugging client program.

S52, after receiving a debugging command which is issued by the debugging client program and used for indicating the corresponding slave core to continue to run the debuggee program, transmitting the debugging command and the breakpoint command to the debugging service terminal program of the corresponding slave core, and clearing the mark so as to inform the debugging service terminal program of the corresponding slave core to exit from the waiting state, and continuing to run the debuggee program after the breakpoint is set according to the break point command.

And S53, entering a waiting state after clearing the mark until exiting the waiting state when the corresponding debuggee program running on the slave core generates the non-maskable interrupt and enables the corresponding debugging service terminal program of the slave core to enter the waiting state again.

In step S53, the communication agent task may be instructed to enter the waiting state by setting a leave NMI exception waiting flag bit to be valid (for example, setting "1" to indicate valid), and setting a leave communication agent task waiting flag bit to be valid (also, setting "1" to indicate valid) to instruct the debuggee program to encounter a breakpoint and cause an enter NMI exception (that is, the corresponding debug service terminal program from the core acquires the processor control right again due to occurrence of the unmasked interrupt and enters the waiting state after uploading the information reported by the breakpoint exception).

And S54, after exiting the waiting state, uploading third breakpoint exception reporting information which is from a debugging service terminal program of a corresponding slave core and is used for reporting that the debuggee program running on the corresponding slave core has the unmasked interrupt to the debugging client program.

In the step S54, the communication agent task may specifically exit from the waiting state by setting the exit NMI exception waiting flag to be invalid (for example, setting "0" to indicate invalid), and then continuously repeating the above steps until receiving the debugging end command issued by the debugging client program. Therefore, through the establishment of at least one communication agent task and the working mode thereof, the multi-core concurrent debugging process can be simplified, the multi-core concurrent debugging process is easy to control and feasible, and the exception of the whole system can be avoided due to no introduction of a competition mechanism.

In addition, since the master core (i.e., core 0) is used as a proxy core, the flag bit of the slave core needs to be changed during the debugging process, and the received debugging command is forwarded to the slave core, and these processes all need to divide the memory address space accessed by the slave core, so as to achieve the purpose of "isolation". Although the data of each core can be protected by the address isolation, the data coverage problem after the program is loaded in the power-on mode is avoided, but the inter-core communication problem, namely the cross-core memory access problem, is caused. Considering that the local L1/L2 memories of each core in the multi-core DSP chip have two inlets in the memory mapping, all the memories local to each core have corresponding global addresses, and a core can access private addresses of other cores through the global addresses, so that cross-core memory access can be realized by utilizing the characteristic.

The corresponding relationship between the core number and the local address and the global address may be as follows:

if core0 needs to read and write the local address 0x00800000 of core1, it can only be realized by reading and writing the global address 0x 11800000. Meanwhile, the problem that cross-core access needs special attention is considered, namely, cache of each core cache is refreshed, namely, each core has an instruction cache ICache and a digital cache DCache, when the memory is read and written, the ICache or the Dcache needs to be refreshed in time, and the problem that the program execution is unpredictable due to inconsistency between the memory and the cache is avoided. Preferably, the debugging service terminal program is further configured to refresh caches of the first core and the second core respectively when the first core accesses the memory of the second core across cores using a global address corresponding to the second core, where the first core and the second core belong to the multi-core DSP chip respectively, and the caches include an instruction cache and a data cache.

Therefore, based on the specific content of the possible design III, the multi-core concurrent debugging process can be simplified through the establishment of the communication agent task and the working mode thereof, so that the process is easy to control and feasible, and due to no introduction of a competition mechanism, the exception of the whole system can be avoided, and the unpredictable problem of program execution caused by the inconsistency of the memory and the cache can be avoided.

In this embodiment, on the basis of the technical solution of the third possible design, a fourth possible design of how to output text data is provided, that is, online debugging is considered to be performed based on an ethernet network, so that an emulator is no longer used in the debugging process, which results in that an existing library function printf cannot be output through an emulator or a serial port when the debugged program is running, and therefore output of text data can only be output to the debugging host through the ethernet network and displayed, and in order to implement a function of outputting text data through the ethernet network, as shown in fig. 9, the debugging client program is further configured to create a thread for receiving and displaying text data from the DSP target machine at startup, where the thread is configured to create a first Socket based on a UDP protocol and bind a port number of the DSP target machine; the debugging service terminal program is further configured to, when the debugging client program is connected to the master core, acquire an IP address of the debugging host, maintain the IP address as a target address of a text output function eprintf, and simultaneously create a text output communication proxy task and a second Socket based on a UDP protocol and used for communicating with the first Socket, where the text output function eprintf is used to mark the master core/slave core that sends text data while outputting text data; the debuggee program is configured to directly use the second Socket to send text data to the debugging client program when the text output function eprint is called on the master core, and set a text buffer address of text data to be sent and enable a text output flag to be valid (for example, "1" is set to indicate valid) in a register corresponding to the slave core when the text output function eprint is called on the slave core, so that the text output communication agent task obtains the text data to be sent in the text buffer according to the text buffer address corresponding to the slave core when polling finds that the text output flag corresponding to the slave core is valid, and sends the text data to be sent to the debugging client program by using the second Socket.

In detail, the using method of the text output function eprintf is completely the same as that of the existing library function printf, that is, when the debuggee program calls the text output function eprintf, the text data to be output will be formatted to generate a character string to be printed; in addition, before sending to the ethernet interface, a data header character "$ O [ corex ]" (where x represents a core number) is added at the start position of the data to mark the master core/slave core sending the text data, so that after receiving, the debugging client program can first judge whether the received text starts with "$ O" and strip it, and then output the received text string to GDB stdionsole. In addition, after the text data of a certain slave core is successfully sent to the debugging client program by using the second Socket, the text output flag bit corresponding to the certain slave core is set to be invalid (for example, the setting of "0" indicates that the text output flag bit is invalid) so as to avoid repeatedly sending the text data; and because the interaction of multi-core data is involved, the caches of the master core and the certain slave core must be refreshed when the text output flag bit is read and written so as to avoid sending failure caused by data confusion.

Therefore, based on the specific content of the possible design four, the function of outputting text data through the Ethernet can be realized in the multi-core concurrent debugging process, and the applicability of the debugging architecture is ensured.

Finally, it should be noted that the present invention is not limited to the above alternative embodiments, and that various other forms of products can be obtained by anyone in light of the present invention. The above detailed description should not be taken as limiting the scope of the invention, which is defined in the claims, and which the description is intended to be interpreted accordingly.

Claims

1. The DSP debugging framework based on the Ethernet is characterized by comprising a debugging host and a DSP target machine which are connected through Ethernet communication, wherein the debugging host runs a debugging client program, the DSP target machine runs a debugged program, and the debugged program comprises a debugging service terminal program compiled in a library file form;

the debugging service terminal program is used for generating an unmasked interrupt when the debugged program executes the illegal instruction by inserting the illegal instruction into the debugged program, acquiring a processor control right when the unmasked interrupt occurs, then storing the context of the debugged program when the unmasked interrupt occurs, transmitting the breakpoint exception report information to the debugging client program, inserting a next illegal instruction into the debugged program according to the debugging command after receiving the debugging command, then recovering the context of the debugged program, returning the processor control right to the debugged program, and enabling the debugged program to continue to run at a pause position;

the debugging service terminal program is further configured to, when the DSP target machine adopts a multi-core DSP chip and runs on a designated master core, take each of the other cores as a slave core, and create at least one communication proxy task on the master core, where the master core and each of the slave cores run the debugged program and the debugging service terminal program independently, the at least one communication proxy task corresponds to the at least one slave core one to one, and each of the at least one communication proxy task is used to monitor a different port number and represents a debugging service terminal program corresponding to the slave core to communicate with the debugging client program;

the working steps of each communication agent task comprise:

and after exiting the waiting state, uploading third breakpoint exception reporting information which comes from the debugging service terminal program of the corresponding slave core and is used for reporting that the debuggee program running on the corresponding slave core generates the unmasked interrupt to the debugging client program.

2. The DSP debugging architecture of claim 1, wherein when the non-maskable interrupt occurs, acquiring a processor control right, then saving a context of the debuggee program when the non-maskable interrupt occurs, transmitting the breakpoint exception report information to the debugging client program, and after receiving the debugging command, inserting a next illegal instruction into the debuggee program according to the debugging command, then restoring the context of the debuggee program, and returning the processor control right to the debuggee program, so that the debuggee program continues to run at a paused place, includes steps S21 to S29:

s23, judging whether the first legal instruction is a 16-bit simplified instruction or a 32-bit instruction, if so, reading a PC value in an instruction counter, taking a new PC value as a current address after the PC value is reduced by 2, and then executing the step S24, and if so, reading the PC value in the instruction counter, taking the PC value as a current address, and then executing the step S24, wherein the instruction counter is used for storing the address of the instruction to be executed by the debugged program currently, and the current address refers to the address of the first instruction executed by the debugged program after the debugged program resumes operation;

s28, judging whether the second legal instruction is a 16-bit simplified instruction or a 32-bit instruction, if so, replacing the second legal instruction at the next instruction address with a 16-bit illegal instruction, and then executing the step S29, and if so, replacing the second legal instruction at the next instruction address with a 32-bit illegal instruction, and then executing the step S29;

and S29, restoring the context of the debuggee program, returning the control right of the processor to the debuggee program so as to restore the operation of the debuggee program, and then returning to execute the step S21.

3. The DSP debugging architecture of claim 2 wherein if it is a 16-bit reduced instruction, replacing the second legal instruction at the next instruction address with a 16-bit illegal instruction, and then performing step S29, comprising:

4. The DSP debugging architecture of claim 2 wherein in step S25, if a debugging command is received as a resume run command, step S29 is directly performed, and if a debugging command is received as another command, the another command is executed and responded, and then step S25 is performed, wherein the another command is a command other than a step execution command and a command other than a resume run command.

5. The DSP debugging architecture of claim 1 wherein the debugging client program is further configured to, during StepOver-type step-through debugging, control the debuggee program to skip calling an API function on the DSP target side according to the following steps:

6. The DSP debugging architecture of claim 1 wherein the debugging client program is further to control the debuggee program to skip calling a third party library function during StepOver type stepping in accordance with the following steps:

receiving second breakpoint exception reporting information which comes from the debugging service terminal program and carries a current address, wherein the second breakpoint exception reporting information is generated and transmitted by triggering the debugging service terminal program when the debugged program encounters a preset breakpoint after executing one-step debugging, and the current address refers to an address of a first instruction executed after the debugged program resumes running;

if so, extracting a target address positioned in a target address register according to the instruction B, wherein the target address register is used for recording an initial address of the third-party library function;

7. The DSP debugging architecture of claim 1 wherein the debugging service terminal program is further configured to flush caches of a first core and a second core, respectively, when the first core accesses a memory of a second core across cores using a global address corresponding to the second core, wherein the first core and the second core belong to the multi-core DSP chip, respectively, and the caches include an instruction cache and a data cache.

8. The DSP debugging architecture of claim 1 wherein the debugging client program is further configured to create a thread for receiving and displaying text data from the DSP target at startup, wherein the thread is configured to create a first Socket based on a UDP protocol and bind a port number of the DSP target;

9. The DSP debugging architecture of claim 1 wherein the debugging client program establishes a communication connection with the debugging service termination program through a remote serial communication protocol, RSP.