A debugging tool and debugging method and system thereof

Abstract

The present application discloses a debugging tool and its debugging method and system. The debugging tool includes a protocol communication processing unit and a debugging instruction processing unit that run in the form of a patch and have a debugging function; the protocol communication processing unit is used to realize communication with an external device; the debugging instruction processing unit is used to process the received debugging instructions, specifically including a debugging instruction processing function entry module, a virtual machine execution controller module and a debugging command parser module. The solution provided by the present application realizes post-loading in the form of a patch, that is, loading when the bytecode needs to be debugged, and performing source code debugging after loading, which can locate bytecode problems more quickly and intuitively and improve debugging efficiency.

Description

Technical Field

[0001] The present application relates to the field of debugging, and in particular to a debugging tool and a debugging method and system thereof. Background Art

[0002] With the development of the times, various smart devices are being generated more and more rapidly. In the production process of smart devices, developers generally reserve some dedicated debugging programs in the product to configure and generate corresponding debugging tools. The debugging tools are used for functional debugging and whole machine testing after the product is generated.

[0003] However, the debugging tools reserved in the smart device occupy a large amount of memory, wasting a large amount of memory space when debugging is not needed, resulting in the debugging process being inflexible. Summary of the invention

[0004] The present application provides a debugging tool, including a protocol communication processing unit and a debugging instruction processing unit that run in a patch form and have a debugging function;

[0005] The protocol communication processing unit is used to establish communication between the debugging tool and the external device;

[0006] The debugging instruction processing unit is used to process the received debugging instructions, and specifically includes a debugging instruction processing function entry module, a virtual machine execution controller module, and a debugging command parser module:

[0007] Among them, after receiving an APDU instruction with a debugging function, entering the debugging instruction processing function entry module, sending the APDU instruction to the virtual machine execution controller module, if the virtual machine execution controller module determines that there is breakpoint information in the APDU instruction, entering the debugging command parser module, recording the breakpoint position in the debugging command parser module, if the virtual machine execution controller module determines that there is no breakpoint information in the APDU instruction, then continuing to execute the bytecode; controlling the virtual machine running state in the virtual machine execution controller module, stopping the virtual machine running when executing to the breakpoint, entering the debugging command parser module, and continuing to execute the bytecode when receiving the bytecode running instruction; if a bytecode debugging instruction is received in the debugging command parser module, parsing and executing the bytecode debugging instruction, if a bytecode running instruction is received, exiting the breakpoint and continuing to run the bytecode.

[0008] As described above, the debugging tool, wherein the debugging instruction processing function entry module exists in the virtual machine execution loop, provides a patch entry point function for debugging related function processing, is used to provide an entry point for debugging related functions of processing instructions during the operation of the virtual machine, and performs debugging processing by entering the patch port function when executing each virtual machine bytecode.

[0009] The debugging tool as described above, wherein the virtual machine execution controller module specifically includes a breakpoint setting submodule, a breakpoint stop submodule, and a virtual machine execution submodule;

[0010] The breakpoint setting module is used in the startup phase or the running phase. If it is determined that there is breakpoint information, the breakpoint information is recorded, and the debugging initialization is completed, and the debugging component information of the application is recorded;

[0011] The breakpoint stop module is used to compare the current address with the pre-stored breakpoint information during the execution of each bytecode. If the corresponding information is matched, the current program has been executed to the breakpoint, the virtual machine is stopped, and the information of the virtual machine stop point and the stop response code are returned to inform it that the breakpoint event has been triggered and the breakpoint stop position, and wait for receiving the next instruction;

[0012] The virtual machine execution module is used to continue executing the bytecode after stopping at a breakpoint when receiving a bytecode execution instruction.

[0013] The present application also provides a debugging method, wherein any of the above-mentioned debugging tools is run in a device to be debugged, and the method comprises:

[0014] In response to receiving an APDU instruction with a debugging function, the device to be debugged enters a debugging instruction processing function entry module and sends the APDU instruction to a virtual machine execution controller module;

[0015] The virtual machine execution controller module determines whether there is breakpoint information in the APDU instruction. If so, it enters the debugging command parser module, records the breakpoint position in the debugging command parser module, returns a setting success response, and waits for receiving the next APDU instruction. Otherwise, it continues to execute the bytecode. If the breakpoint position has been recorded, the virtual machine is stopped when the breakpoint is executed, and the information of the virtual machine stop position and the stop response code are returned, and the next APDU instruction is waited for receiving;

[0016] In response to receiving the bytecode debugging instruction, the debugging command parser module parses the bytecode debugging instruction in the breakpoint triggering stage, performs the corresponding debugging operation according to the bytecode debugging instruction, returns the debugging result, and waits for receiving the next instruction;

[0017] In response to receiving the bytecode execution instruction, the breakpoint is exited, and the bytecode is continued to be executed in the virtual machine execution controller module according to the bytecode execution instruction.

[0018] In the debugging method as described above, the device to be debugged includes a physical smart device or a simulated smart device application.

[0019] In the debugging method as described above, the APDU instruction with debugging function is an instruction for setting breakpoints, running bytecodes or debugging bytecodes in the device to be debugged by a debugger program set in the host computer through a user debugging interface.

[0020] In the debugging method as described above, the device to be debugged receives a preset breakpoint instruction during the startup phase, or receives a breakpoint instruction set according to user requirements during the running process.

[0021] In the debugging method as described above, the device to be debugged compares the current bytecode address with the stored breakpoint information when executing each bytecode. If the information matches, it means that the execution reaches the breakpoint and the virtual machine operation state is stopped, otherwise the bytecode continues to be executed.

[0022] The debugging method as described above, wherein, in response to receiving a bytecode execution instruction, the breakpoint is exited, and the bytecode is continued to be executed according to the bytecode execution instruction, specifically including: when a single-step execution instruction is received, the virtual machine is stopped after executing the next bytecode, and if a full-speed execution instruction is received, the virtual machine is run at full speed until the next breakpoint is encountered and the virtual machine is stopped again.

[0023] The present application also provides a debugging system, comprising a device to be debugged that runs any of the debugging tools described above, and a host computer; the device to be debugged establishes a communication connection with the host computer through a protocol communication processing unit, and the device to be debugged executes any of the debugging methods described above.

[0024] The beneficial effects achieved by the present application are as follows: the debugging tool and its debugging method and system adopted by the present application realize post-loading in the form of a patch, that is, the instructions are loaded when the bytecode needs to be debugged, and after the instructions are loaded, the Java source code can be debugged, which is convenient for finding application problems, and can locate bytecode problems more quickly and intuitively, thereby improving debugging efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0026] Figure 1 It is a schematic diagram of a debugging system provided in Embodiments 1 and 2 of the present application;

[0027] Figure 2 This is a flowchart of a debugging method provided in Example 3 of the present application;

[0028] Figure 3 It is a system flow chart of a debugging method provided in Example 4 of the present application. DETAILED DESCRIPTION

[0029] The following is a clear and complete description of the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0030] Embodiment 1

[0031] The first embodiment of the present application provides a debugging tool, such as Figure 1 As shown, it includes: a protocol communication processing unit 11 and a debugging instruction processing unit 12 which run in the form of a patch and have a debugging function;

[0032] The protocol communication processing unit 11 is used to establish a communication connection between the debugging tool and the host computer, specifically to receive the debugging instructions sent by the host computer according to the predefined communication protocol. The predefined protocol includes processing the data header, receiving data, setting the sending length, sending data, and sending the status word;

[0033] The debugging instruction processing unit 12 is used to process the received debugging instructions, and specifically includes a debugging instruction processing function entry module 121, a virtual machine execution controller module 122 and a debugging command parser module 123:

[0034] Among them, after receiving an APDU instruction with a debugging function, the debugging instruction processing function entry module 121 is entered, and the APDU instruction is sent to the virtual machine execution controller module 122. If the virtual machine execution controller module 122 determines that there is breakpoint information in the APDU instruction, the debugging command parser module 123 is entered, and the breakpoint position is recorded in the debugging command parser module 123. If the virtual machine execution controller module 122 determines that there is no breakpoint information in the APDU instruction, the bytecode is continued to be executed; the virtual machine running state is controlled in the virtual machine execution controller module 122, and the virtual machine running is stopped when the execution reaches the breakpoint, and the debugging command parser module 123 is entered, and the bytecode is continued to be executed when the bytecode running instruction is received; if a bytecode debugging instruction is received in the debugging command parser module 123, the bytecode debugging instruction is parsed and executed, and if a bytecode running instruction is received, the breakpoint is exited and the bytecode is continued to be run.

[0035] Specifically, the debugging instruction processing unit 12 is used to process APDU instructions with debugging functions, and the APDU instructions with debugging functions specifically include initializing debugging information, setting breakpoints, single-step execution, obtaining the internal state of the virtual machine, modifying or reading variable values, and other functional instructions; wherein the debugging instruction processing unit 12 specifically includes:

[0036] ① The debugging instruction processing function entry module 121 exists in the virtual machine execution loop, and provides a patch entry point function for debugging related function processing, which is used to provide an entry point for debugging related functions of processing instructions during the operation of the virtual machine, and performs debugging processing by entering the patch port function when executing each virtual machine bytecode;

[0037] ② The virtual machine execution controller module 122 is used to start or pause the operation of the virtual machine, and implement functions such as breakpoint stop or single-step execution. Its main function is to control the operation state of the virtual machine: such as breakpoint stop, single-step execution, full-speed operation and other operations, thereby realizing functions such as setting breakpoints and single-step debugging of the application program; the virtual machine execution controller module 122 specifically includes a breakpoint setting submodule 1221, a breakpoint stop submodule 1222, and a virtual machine execution submodule 1223, each of which is specifically used for:

[0038] The breakpoint setting module 1221 is used to interact with the host computer during the startup phase. If it is learned that the host computer has set a breakpoint, the breakpoint information is recorded, the breakpoint setting is completed, the debugging initialization of the device to be debugged is completed, and the debugging component information of the application is recorded; and it is used to receive the breakpoint setting instruction sent by the host computer during the interaction process. At this time, the breakpoint setting instruction is that the user sets a breakpoint on the Applet, and the host computer sends the address corresponding to the breakpoint to the device to be debugged through an instruction, thereby completing the breakpoint setting.

[0039] The breakpoint stop module 1222 is used to compare the current address with the pre-stored breakpoint information during the execution of each bytecode of the application. If the corresponding information is matched, it proves that the current program has been executed to the breakpoint. The virtual machine execution controller will stop the virtual machine and send the information of the virtual machine stop point and the stop response code data to the host computer, informing the host computer that the breakpoint event has been triggered and the breakpoint stop position, and wait to receive the next debugging instruction; the host computer will correctly display the cursor at the code breakpoint position in the user debugging interface based on the response information obtained.

[0040] The virtual machine execution module 1223 is used to continue executing the bytecode after stopping at a breakpoint when receiving a bytecode execution instruction sent by the host computer; specifically, if a single-step instruction is received from the host computer, the virtual machine is stopped after executing the next bytecode; if a full-speed run instruction is received from the host computer, the bytecode is run until the next breakpoint is encountered and the virtual machine is stopped.

[0041] The virtual machine of the device to be debugged stops running and waits for the next debugging instruction; after the user's subsequent operation, subsequent processing is performed according to the received debugging instruction, for example, the virtual machine is stopped after single-step execution reaches the next bytecode; the virtual machine is stopped when running at full speed and encountering the next breakpoint, etc.

[0042] Among them, after the virtual machine of the device to be debugged stops running, the code can be debugged through the host computer interface, and the host computer sends the corresponding bytecode debugging instructions to the device to be debugged for processing.

[0043] ③ The debugging command parser 123 is used to parse the bytecode debugging instructions sent by the upper computer, such as realizing the functions of obtaining the internal state of the virtual machine, modifying or reading the variable value, etc. The main function is to parse the instructions sent by the upper computer, process the instructions, send the corresponding response data after the processing is completed, and wait for the next instruction to be received, and repeat the cycle until the processing is completed and the debugging command parser loop is exited.

[0044] Embodiment 2

[0045] Embodiment 2 of the present application provides a debugging system, such as Figure 1 As shown, it includes a device to be debugged 1 running the debugging tool described in Example 1, and a host computer 2; the device to be debugged 1 establishes a communication connection with the host computer 2 through a protocol communication processing unit 11.

[0046] The host computer 2 realizes the functions of setting breakpoints in the device to be debugged, executing Java applet code in a single step, and viewing and modifying variables in the Java applet code through the user debugging interface.

[0047] When the device to be debugged informs the host computer of the response data of the breakpoint event being triggered and the position where the breakpoint stops, the host computer correctly displays the cursor at the code breakpoint position in the user debugging interface according to the response data.

[0048] In addition, after the virtual machine of the device to be debugged stops running, the code is debugged on the user debugging interface of the host computer, and the host computer sends the instructions corresponding to the debugging code operation to the device to be debugged for processing again.

[0049] Embodiment 3

[0050] Embodiment 3 of the present application provides a debugging method, in which the debugging tool described in Embodiment 1 is run in the device to be debugged, wherein the device to be debugged may be a physical smart device (such as a smart card, security hardware, etc.) or a simulated smart device application. If it is a physical smart device, a communication connection is established with a host computer through a card reader; if it is a simulated smart device application, a communication connection is established with the host computer directly using a predefined communication protocol.

[0051] In the embodiment of the present application, a processing mechanism having a protocol communication processing unit and a debugging instruction processing unit is run on the basis of the original processor of the device to be debugged. Preferably, the processing mechanism is run on the processor of the device to be debugged in the form of a patch to realize post-loading, or the processing mechanism can be pre-set in the device to be debugged; the device to be debugged establishes a communication connection with the host computer according to the protocol communication processing unit, and debugs with the host computer according to the debugging instruction processing unit, such as Figure 2 As shown, the debugging method specifically includes the following steps:

[0052] Step 210: In response to receiving the APDU instruction with debugging function sent by the host computer, the device to be debugged enters the debugging instruction processing function entry module and sends the APDU instruction to the virtual machine execution controller module;

[0053] In the embodiment of the present application, the APDU instructions sent by the host computer received by the device to be debugged include APDU instructions with debugging functions (including setting breakpoint instructions, running bytecode instructions or bytecode debugging instructions, etc.) and other communication instructions. When it is determined that the instruction identifier in the received APDU instruction indicates an APDU instruction with debugging function, the debugging instruction processing unit is entered; wherein the APDU instruction with debugging function is implemented by a debugger program set in the host computer through a user debugging interface to set breakpoints in the device to be debugged, single-step execute Java applet codes, view and modify variables in Java applet codes, etc.;

[0054] The debugging instruction processing unit includes a debugging instruction processing function entry module, a virtual machine execution controller module and a debugging command parser module; wherein the debugging instruction processing function entry module exists in the virtual machine execution loop, provides an entry point function for debugging related function processing, and is used to provide an entry point for debugging related functions of processing instructions during the operation of the virtual machine. During the execution of each virtual machine bytecode, the entry point function needs to be called to enter the debugging processing program;

[0055] The APDU instruction for setting a breakpoint sent by the host computer may be a breakpoint pre-set by the host computer when the device to be debugged is started, or may be a breakpoint set according to user requirements during the execution of the host computer.

[0056] Step 220, the virtual machine execution controller module determines whether there is breakpoint information in the APDU instruction, if yes, enters the debug command parser module, records the breakpoint position in the debug command parser module, returns a successful setting response, and waits for receiving the next APDU instruction, otherwise continues to execute the bytecode, if the breakpoint position has been recorded, stops the virtual machine when executing to the breakpoint, returns the information of the virtual machine stop position and the stop response code, and waits for receiving the next APDU instruction;

[0057] When the device to be debugged records a breakpoint according to the received instruction, and after receiving the next APDU instruction for executing the bytecode, if the APDU instruction is a bytecode execution instruction, the device to be debugged continues to execute the bytecode until the recorded breakpoint is reached and the virtual machine stops running;

[0058] In the embodiment of the present application, in the debugging instruction processing unit, after receiving the APDU instruction in the debugging instruction processing function entry module, the virtual machine execution controller module is entered; the virtual machine execution controller module is used to control the running state of the virtual machine, including starting or pausing the running of the virtual machine, realizing breakpoint stop or single-step execution and other functions, such as breakpoint stop, single-step execution, full-speed execution and other operations, thereby realizing the host computer setting breakpoints, single-step debugging and other functions in the device to be debugged; the bytecode is run in the virtual machine execution controller module, if the breakpoint information is recorded in the device to be debugged, when the device to be debugged executes to the breakpoint line of the Java applet code, the running state of the virtual machine is stopped, and an instruction is sent to inform the host computer that the execution has reached the breakpoint, and the host computer stops at the breakpoint line set in the Java applet code after receiving the instruction;

[0059] Specifically, the virtual machine execution controller module specifically includes a breakpoint setting submodule, a breakpoint stop submodule and a virtual machine execution submodule; if the breakpoint is not set, the device to be debugged executes the subsequent program; if the breakpoint is set, the breakpoint setting module and the breakpoint stop module are called to stop the device to be debugged at the breakpoint, so that the debugger program interface can stop at the breakpoint line of the java applet source code, and the program will no longer continue to execute. Only when the debugger has other operations, the device to be debugged will continue to execute;

[0060] The breakpoint setting submodule is used to set a breakpoint according to the debugging instruction after receiving the debugging instruction containing the breakpoint information; the breakpoint stop submodule is used to start executing the bytecode after setting the breakpoint, and when executing each bytecode, when the current bytecode address is matched with the stored breakpoint information, the virtual machine running state is stopped; the virtual machine execution submodule is used to wait for the arrival of the next debugging instruction after stopping at the breakpoint;

[0061] Specifically, the specific operations of each submodule are as follows:

[0062] The breakpoint setting submodule will interact with the host computer during the startup phase. When it is determined that a breakpoint is set in the debugging instruction sent by the host computer, the breakpoint information is recorded, the breakpoint setting is completed, and the debugging initialization of the device to be debugged is completed, and the debugging component information of the device to be debugged is recorded;

[0063] The breakpoint stop submodule starts running the virtual machine after receiving the data from the host computer. During the execution of each bytecode of the application, the current address will be compared with the pre-stored breakpoint information. If the corresponding information is matched, it proves that the current application has been executed to the breakpoint. The virtual machine execution controller will stop the virtual machine and send the address information of the virtual machine stop point and the stop response code data to the host computer to inform the host computer that the breakpoint event has been triggered and the breakpoint stop position. The host computer will display the cursor correctly at the code breakpoint position in the user debugging interface according to the response information;

[0064] The virtual machine execution submodule is used to stop the virtual machine from running and wait for the next debugging instruction after stopping at a breakpoint; at this time, the code can be debugged through the user debugging interface of the host computer, and the host computer sends the corresponding debugging instruction to the device to be debugged for processing.

[0065] Step 230: In response to receiving the bytecode debugging instruction, the debugging command parser module parses the bytecode debugging instruction in the breakpoint triggering stage, performs the corresponding debugging operation according to the bytecode debugging instruction, returns the debugging result, and waits for receiving the next instruction;

[0066] During the period when the device to be debugged stops the running of the virtual machine at the breakpoint, the host computer can send bytecode debugging instructions to the device to be debugged according to user needs, such as query instructions, including instructions for obtaining version information, obtaining the value of a static field, setting the value of a static field, etc.; thereby, the device to be debugged can query the above information during the process of stopping the running of the virtual machine;

[0067] In the embodiment of the present application, after the virtual machine execution controller module executes to the breakpoint to stop the operation of the virtual machine, the debugging command parser module is entered. If the above query instruction is received, the above query instruction is parsed and processed in the debugging command parser module.

[0068] Step 240: In response to receiving the bytecode execution instruction, exit the breakpoint, and continue to execute the bytecode according to the bytecode execution instruction in the virtual machine execution controller module;

[0069] During the period when the device to be debugged stops the running of the virtual machine at the breakpoint, the host computer can also send a single-step execution instruction or a full-speed running instruction to the device to be debugged according to user needs. The single-step running instruction includes a single-step execution into a sub-function instruction, a single-step execution skipping a sub-function but the sub-function will execute an instruction, and when the single-step execution enters the sub-function, the remaining part of the sub-function is executed and the return to the upper layer function is executed. If a single-step running instruction is received, the virtual machine is stopped after executing to the next bytecode. If a full-speed running instruction sent by the host computer is received, the virtual machine is run at full speed until the next breakpoint is encountered and the virtual machine is stopped again.

[0070] In an embodiment of the present application, after the virtual machine execution controller module executes to the breakpoint to stop the virtual machine operation, the debugging command parser module is entered. If the above-mentioned single-step execution instruction is received, the debugging command parser module is exited and the debugging device continues to execute the single-step execution instruction operation.

[0071] Embodiment 4

[0072] Embodiment 4 of the present application provides a debugging method, in which command communication is performed between the device to be debugged and the host computer, such as Figure 3 As shown, the method includes:

[0073] In the startup phase, the device to be debugged establishes a communication connection with the host computer. Various debugging instructions are set by the host computer debugging interface in the DEBUG instruction parser loop. When the host computer issues a startup instruction to the device to be debugged, the device to be debugged exits the DEBUG instruction parser and enters the instruction communication interaction loop to receive the debugging instructions issued by the host computer.

[0074] When the device to be debugged receives the complete debugging instruction, it starts the virtual machine execution loop, first calls the debugging patch entry point function to enter the debugging instruction processing function entry module, sends the instruction to the virtual machine execution controller module, and continues to enter the virtual machine execution controller module for operation;

[0075] After entering the virtual machine execution controller module, the virtual machine execution controller module determines whether there is breakpoint information in the instruction. If yes, it enters the debugging command parser to record the breakpoint position. Otherwise, when the virtual machine execution controller module executes to the breakpoint position, it controls the virtual machine to stop running, and sends the virtual machine stop address and response code to the host computer; the host computer correctly displays the cursor at the code breakpoint stop position on the user debugging interface, and enters the debugging command parser loop after the breakpoint stops and waits to receive the next debugging instruction;

[0076] When the host computer sends the corresponding debugging instructions to the device to be debugged according to user requirements, the debugging command parser module processes the debugging instructions; if the debugging command parser module receives instructions related to single-step execution instructions, it exits the debugging command parser loop, starts the virtual machine bytecode execution loop, parses and executes the bytecode, exits the virtual machine bytecode execution loop after the instruction is executed, and enters the instruction communication interaction loop to receive the instruction again.

[0077] The above-described embodiments are only specific implementation methods of the present application, which are used to illustrate the technical solutions of the present application, rather than to limit them. The protection scope of the present application is not limited thereto. Although the present application is described in detail with reference to the aforementioned embodiments, ordinary technicians in the field should understand that any technician familiar with the technical field can still modify the technical solutions recorded in the aforementioned embodiments within the technical scope disclosed in the present application, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application. They should all be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A debugging tool, characterized in that: It includes a protocol communication processing unit and a debugging instruction processing unit that run in the form of a patch and have debugging functions; the protocol communication processing unit is used to realize communication with external devices; the debugging instruction processing unit is used to process received debugging instructions, specifically including a debugging instruction processing function entry module, a virtual machine execution controller module and a debugging command parser module: Wherein, after receiving an APDU instruction with a debugging function, entering a debugging instruction processing function entry module, sending the APDU instruction to a virtual machine execution controller module, if the virtual machine execution controller module determines that there is breakpoint information in the APDU instruction, entering a debugging command parser module, recording the breakpoint position in the debugging command parser module, if the virtual machine execution controller module determines that there is no breakpoint information in the APDU instruction, continuing to execute the bytecode; controlling the virtual machine running state in the virtual machine execution controller module, stopping the virtual machine running when executing to a breakpoint, entering a debugging command parser module, and continuing to execute the bytecode when receiving a bytecode running instruction; if a bytecode debugging instruction is received in the debugging command parser module, parsing and executing the bytecode debugging instruction, if a bytecode running instruction is received, exiting the breakpoint and continuing to run the bytecode; Among them, after the virtual machine stops running, the code is debugged through the host computer interface, and the host computer sends the corresponding bytecode debugging instructions to the device to be debugged for processing; Among them, a processing mechanism having a protocol communication processing unit and a debugging instruction processing unit is run on the basis of the original processor of the device to be debugged; the processing mechanism is run on the processor of the device to be debugged in the form of a patch to realize post-loading, or the processing mechanism is pre-set in the device to be debugged; The debugging instruction processing function entry module exists in the virtual machine execution loop, and provides a patch entry point function for debugging related function processing, which is used to provide an entry point for debugging related functions of processing instructions during the operation of the virtual machine, and performs debugging processing by entering the patch port function when executing each virtual machine bytecode.

2. The debugging tool according to claim 1, characterized in that: The virtual machine execution controller module specifically includes a breakpoint setting submodule, a breakpoint stop submodule, and a virtual machine execution submodule; The breakpoint setting module is used in the startup phase or the running phase. If it is determined that there is breakpoint information, the breakpoint information is recorded, and the debugging initialization is completed, and the debugging component information of the application is recorded; The breakpoint stop module is used to compare the current address with the pre-stored breakpoint information during the execution of each bytecode. If the corresponding information is matched, the current program has been executed to the breakpoint, the virtual machine is stopped, and the information of the virtual machine stop point and the stop response code are returned to inform it that the breakpoint event has been triggered and the breakpoint stop position, and wait for receiving the next instruction; The virtual machine execution module is used to continue executing the bytecode after stopping at a breakpoint when receiving a bytecode execution instruction.

3. A debugging method, characterized in that: The debugging tool according to claim 1 or 2 is run in the device to be debugged, and the method comprises: In response to receiving an APDU instruction with a debugging function, the device to be debugged enters a debugging instruction processing function entry module and sends the APDU instruction to a virtual machine execution controller module; The virtual machine execution controller module determines whether there is breakpoint information in the APDU instruction. If so, it enters the debugging command parser module, records the breakpoint position in the debugging command parser module, returns a setting success response, and waits for receiving the next APDU instruction. Otherwise, it continues to execute the bytecode. If the breakpoint position has been recorded, the virtual machine is stopped when the breakpoint is executed, and the information of the virtual machine stop position and the stop response code are returned, and the next APDU instruction is waited for receiving; In response to receiving the bytecode debugging instruction, the debugging command parser module parses the bytecode debugging instruction in the breakpoint triggering stage, performs the corresponding debugging operation according to the bytecode debugging instruction, returns the debugging result, and waits for receiving the next instruction; In response to receiving the bytecode execution instruction, the breakpoint is exited, and the bytecode is continued to be executed in the virtual machine execution controller module according to the bytecode execution instruction.

4. The debugging method according to claim 3, characterized in that: The device to be debugged includes a physical smart device or a simulated smart device application.

5. The debugging method according to claim 4, characterized in that: The APDU instruction with debugging function is an instruction for setting breakpoints, running bytecodes or debugging bytecodes in the device to be debugged by a debugger program set in the host computer through a user debugging interface.

6. The debugging method according to claim 4, characterized in that: The device to be debugged receives a pre-set breakpoint instruction during the startup phase, or receives a breakpoint instruction set according to user requirements during operation.

7. The debugging method according to claim 4, characterized in that: When executing each bytecode, the device to be debugged compares the current bytecode address with the stored breakpoint information to see if it matches. If the information matches, it means that the execution reaches the breakpoint and the virtual machine running state is stopped, otherwise the bytecode continues to be executed.

8. The debugging method according to claim 4, characterized in that: In response to receiving a bytecode execution instruction, exiting the breakpoint, and continuing to execute the bytecode according to the bytecode execution instruction, specifically including: when a single-step execution instruction is received, executing to the next bytecode and then stopping the virtual machine; if a full-speed execution instruction is received, running the virtual machine at full speed until encountering the next breakpoint and then stopping the virtual machine again.

9. A debugging system, characterized in that: It comprises a device to be debugged running the debugging tool as described in claim 1 or 2, and a host computer; the device to be debugged establishes a communication connection with the host computer through a protocol communication processing unit, and the device to be debugged executes the debugging method as described in any one of claims 3-8.

Images