CN113342654B

CN113342654B - Script language code debugging method and device, readable storage medium and electronic equipment

Info

Publication number: CN113342654B
Application number: CN202110635215.0A
Authority: CN
Inventors: 明畅; 田宛欣
Original assignee: Guangzhou Boguan Information Technology Co Ltd
Current assignee: Guangzhou Boguan Information Technology Co Ltd
Priority date: 2021-06-08
Filing date: 2021-06-08
Publication date: 2024-04-09
Anticipated expiration: 2041-06-08
Also published as: CN113342654A

Abstract

The disclosure relates to the technical field of computers, and provides a script language code debugging method and device, a computer storage medium and electronic equipment. The method comprises the following steps: acquiring a first position attribute of an operation code currently executed in a virtual machine, wherein the first position attribute comprises an identification of a target script code file to which the operation code belongs and position information of a script code corresponding to the operation code in the target script code file; matching the first position attribute with a second position attribute of a breakpoint configured in a preset breakpoint storage container; and when the matching is successful, calling a preset breakpoint jump function to trigger a breakpoint debugging function at the operation code. The method and the device can improve the debugging efficiency of the script language code based on the position attribute of the configuration breakpoint in the preset breakpoint storage container.

Description

Script language code debugging method and device, readable storage medium and electronic equipment

Technical Field

The present disclosure relates to the field of computer technology, and in particular, to a scripting language code debugging method, a scripting language code debugging device, a computer-readable storage medium, and an electronic device.

Background

The LPC language (programming language developed by Lars Pensj ǒ) is a scripting language developed based on the grammar of the C language. As a scripting language, the compilation and execution of LPC code is accomplished by its specialized engine drivers. While writing of code inevitably generates errors, a programmer needs to debug the code when errors occur.

In the related art, a GDB tool (GDB is a program debug tool under UNIX issued by GNU open source organization) is used to debug an LPC script executed in an engine virtual machine. The execution position in the virtual machine is the same no matter which line of which LPC file the current opcode (operation code) corresponding to the LPC script executed by the virtual machine belongs to. Therefore, when using the GDB to set a breakpoint at a specified LPC file and line number, it is necessary to insert a corresponding breakpoint setting code at a different place of the LPC file.

However, this approach requires manual addition of breakpoint setting codes, and after debugging is completed, the added debugging codes need to be manually deleted to prevent confusion with the original codes, thus greatly reducing the debugging efficiency of the LPC codes.

It should be noted that the information disclosed in the above background section is only for enhancing understanding of the background of the present disclosure and thus may include information that does not constitute prior art known to those of ordinary skill in the art.

Disclosure of Invention

The disclosure aims to provide a script language code debugging method and device, a computer readable storage medium and an electronic device, so as to solve the problem of low efficiency when a GDB tool is directly used for debugging the script language code in the related technology at least to a certain extent.

Other features and advantages of the present disclosure will be apparent from the following detailed description, or may be learned in part by the practice of the disclosure.

According to a first aspect of the present disclosure, there is provided a scripting language code debugging method, including:

acquiring a first position attribute of an operation code currently executed in a virtual machine, wherein the first position attribute comprises an identification of a target script code file to which the operation code belongs and position information of a script code corresponding to the operation code in the target script code file;

matching the first position attribute with a second position attribute of a breakpoint configured in a preset breakpoint storage container;

and when the matching is successful, calling a preset breakpoint jump function to trigger a breakpoint debugging function at the operation code.

In an exemplary embodiment of the present disclosure, based on the foregoing solution, the preset breakpoint storage container includes a preset breakpoint storage array, and breakpoint data stored by each element in the preset breakpoint storage array includes a second location attribute of the breakpoint and a breakpoint state of the element;

The second position attribute of the breakpoint comprises an identification of a script code file to which the breakpoint belongs and position information of the breakpoint in the script code file;

the breakpoint states of the element include a first state in which no breakpoints are stored or in which stored breakpoints have been removed, a second state in which a stored breakpoint is invalid, and a third state in which a stored breakpoint is valid.

In an exemplary embodiment of the present disclosure, based on the foregoing scheme, the method further includes:

responding to an operation instruction for adding a target breakpoint, traversing the elements in the preset breakpoint storage array according to the ascending order of index values of the elements, storing second position attributes of the target breakpoint into the elements when traversing to the elements with the breakpoint states of a first state, and reconfiguring the breakpoint states of the elements to a third state;

in response to an operation instruction for removing a target breakpoint, reconfiguring a breakpoint state of a target element corresponding to the target breakpoint into a first state, and when an element to be adjusted with the breakpoint state being a second state or a third state exists after the target element corresponding to the target breakpoint, sequentially advancing breakpoint data stored in the element to be adjusted to a previous element corresponding to the element to be adjusted for storage;

And in the preset breakpoint storage array, the index value of the element to be adjusted positioned behind the target element is larger than the index value of the target element.

responding to an invalid state configuration instruction aiming at a target breakpoint, and reconfiguring a breakpoint state of a target element corresponding to the target breakpoint into a second state in the preset breakpoint storage array;

responding to an effective state configuration instruction aiming at a target breakpoint, and reconfiguring a breakpoint state of a target element corresponding to the target breakpoint into a third state in the preset breakpoint storage array;

and responding to a breakpoint query operation instruction, querying breakpoint data stored in the preset breakpoint storage array, and displaying the queried breakpoint data on the client according to a first preset format.

In an exemplary embodiment of the present disclosure, based on the foregoing solution, the matching the first location attribute with a second location attribute of a breakpoint configured in a preset breakpoint storage container includes:

traversing the elements in the preset breakpoint storage array according to the ascending sequence of the index values of the elements in the preset breakpoint storage array;

And stopping traversing and determining that the first position attribute is successfully matched with the second position attribute of the breakpoint configured in the preset breakpoint storage container when traversing to the element with the second position attribute which is the same as the first position attribute and the breakpoint state is the third state.

and stopping traversing and determining that the first position attribute is failed to match with the second position attribute of the breakpoint configured in the preset breakpoint container when traversing to the element with the stored breakpoint state being the first state, so that the virtual machine continues to execute the next operation code.

and when the interrupt mode is running to the next breakpoint, matching the first position attribute with the second position attribute of the breakpoint configured in the preset breakpoint storage container.

When the interrupt mode is single-step jump, if the current call stack depth of the virtual machine is not greater than the last call stack depth, calling a preset breakpoint jump function to trigger a breakpoint debugging function at the operation code;

when the interrupt mode is single-step entry, if the current call stack depth of the virtual machine is not less than the last call stack depth, calling a preset breakpoint jump function to trigger a breakpoint debugging function at the operation code;

when the interrupt mode is single-step completion, if the current call stack depth of the virtual machine is smaller than the last call stack depth, a preset breakpoint jump function is called to trigger a breakpoint debugging function at the operation code.

and responding to a preset code debugging instruction, starting a code debugging process, and adding a breakpoint debugging function at a preset breakpoint jump function to trigger the breakpoint debugging function when the preset breakpoint jump function is called.

if the preset breakpoint jump function triggers a breakpoint debugging function, a first position attribute of the operation code is obtained;

Based on the first position attribute, reading a script code to be printed in a target script code file to which the operation code belongs;

displaying script codes corresponding to the operation codes and the script codes to be printed on the client according to a second preset format;

the script code to be printed comprises script codes, wherein the script codes to be printed are included in the target script code file, and the difference value of the position information of the script codes corresponding to the operation codes is within a preset threshold value.

In an exemplary embodiment of the disclosure, based on the foregoing solution, after triggering the breakpoint debug function at the opcode, the method further includes:

responding to a checking instruction aiming at a target global variable value during the current interruption, calling a first preset function to inquire the target global variable value, and generating a first serialization character string of the target global variable value so as to display the first serialization character string on a client;

and in response to a modification instruction aiming at a target global variable value during the current interrupt, invoking a second preset function to deserialize the target global variable value in the modification instruction, and assigning the deserialized target global variable value to the target global variable.

responding to a checking instruction aiming at a target local variable value in the current interrupt period, calling a third preset function to determine an index value of the target local variable based on a pre-generated local variable index table, inquiring a target local variable value corresponding to the target local variable according to the index value, and generating a second serialized character string of the target local variable value so as to display the second serialized character string on a client;

and calling a fourth preset function to deserialize a target local variable value in a modification instruction in response to the modification instruction aiming at the target local variable value in the current interrupt period, determining an index value corresponding to the target local variable based on a pre-generated local variable index table, and assigning the deserialized target local variable value to the target local variable according to the index value.

In an exemplary embodiment of the present disclosure, based on the foregoing scheme, the local variable index table is generated in advance by:

when compiling the script code file, aiming at each parsed local variable definition, acquiring the identification of the script code file to which the local variable belongs, the identification of the function to which the local variable belongs, the position information of the local variable and the defined sequence of the local variable in the local variable contained in the function;

Storing the identification of the local variable, the position information of the local variable and the defined sequence of the local variable in a local variable index table determined according to the identification of the script code file and the identification of the function so as to generate the local variable index table of the function;

wherein the location information of the local variable comprises location information of the local variable definition in the script code file;

in an exemplary embodiment of the present disclosure, based on the foregoing solution, the determining, based on a pre-generated local variable index table, an index value corresponding to a target local variable includes:

responding to a checking instruction or a modifying instruction aiming at a target local variable value during the current interruption, and acquiring an identification of a target script code file and an identification of a target function to which a current breakpoint causing the current interruption belongs so as to determine a local variable index table to be queried;

determining the local variable to be queried, which is the same as the identification of the target local variable in the checking instruction or the modifying instruction and has the position information smaller than or equal to the position information of the current breakpoint in the target script code file, from the local variable index table to be queried;

Determining a local variable to be queried with the minimum difference value between the position information and the position information of the current breakpoint in the target code file as a target local variable;

and determining an index value corresponding to the target local variable in the checking instruction or the modifying instruction according to the defined sequence corresponding to the target local variable.

and calling a fifth preset function to traverse a stack frame of the virtual machine in response to a viewing instruction of a call stack at the current breakpoint during the current interrupt to acquire call stack information at the current breakpoint, and displaying the call stack information at the current breakpoint at the client according to a third preset format.

in response to a call instruction aiming at a target script function during the current interrupt, calling a sixth preset function to execute the target script function;

wherein the calling the sixth preset function to execute the target script function includes:

Moving the identification of the script file to which the target script function belongs, the identification of the target script function and the value of at least one calling parameter contained in the calling instruction to the stack top of a runtime stack of the virtual machine;

executing the target script function based on the identification of the script file in the stack top of the runtime stack, the identification of the target script function and the value of the calling parameter, and storing the return value of the target script function to the stack top of the runtime stack;

acquiring a return value of the target script function from the stack top of the runtime stack for output;

and restoring the stack top of the runtime stack to a state before executing the target script function.

According to a second aspect of the present disclosure, there is provided a scripting language code debugging device, comprising:

a first location attribute obtaining module configured to obtain a first location attribute of an operation code currently executed in a virtual machine, where the first location attribute includes an identifier of a target script code file to which the operation code belongs and location information of a script code corresponding to the operation code in the target script code file;

the position attribute matching module is configured to match the first position attribute with a second position attribute of a breakpoint configured in a preset breakpoint storage container;

And the breakpoint debugging function triggering module is configured to call a preset breakpoint jump function to trigger the breakpoint debugging function at the operation code when the matching is successful.

According to a third aspect of the present disclosure, there is provided a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the scripting language code debugging method according to the first aspect of the above-described embodiments.

According to a fourth aspect of embodiments of the present disclosure, there is provided an electronic device, comprising: a processor; and storage means for storing one or more programs which, when executed by the one or more processors, cause the one or more processors to implement the scripting language code debugging method according to the first aspect of the above embodiments.

As can be seen from the above technical solutions, the script language code debugging method, the script language code debugging device, and the computer-readable storage medium and the electronic device for implementing the script language code debugging method in the exemplary embodiments of the present disclosure have at least the following advantages and positive effects:

in the technical solutions provided in some embodiments of the present disclosure, first, a first location attribute of an operation code currently executed in a virtual machine is obtained and a second location attribute of a breakpoint configured in a preset breakpoint storage container is matched; and then, when the matching is successful, calling a preset breakpoint jump function to trigger a breakpoint debugging function at the operation code. Compared with the related art, on one hand, in the method, the breakpoint in code debugging is configured in the preset breakpoint storage container, so that the efficiency of setting the breakpoint can be improved; on the other hand, the method and the device can avoid the influence of frequent interrupt-condition judgment-continuous execution process of the virtual machine process on code debugging performance in the related technology by matching the first position attribute of the operation code currently executed in the virtual machine with the second position attribute of the breakpoint configured in the preset breakpoint storage container so as to trigger the breakpoint debugging function, and improve the code debugging efficiency.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the disclosure and together with the description, serve to explain the principles of the disclosure. It will be apparent to those of ordinary skill in the art that the drawings in the following description are merely examples of the disclosure and that other drawings may be derived from them without undue effort.

FIG. 1 illustrates a flow diagram of a scripting language code debugging method in an exemplary embodiment of the present disclosure;

FIG. 2 is a diagram illustrating a memory structure of a preset breakpoint memory array in an exemplary embodiment of the present disclosure;

FIG. 3 illustrates a flow diagram of a method of adding a breakpoint in an exemplary embodiment of the present disclosure;

FIG. 4 illustrates a flow diagram of a method of removing a breakpoint in an exemplary embodiment of the present disclosure;

FIG. 5 is a diagram illustrating the state of a preset breakpoint storage array before and after breakpoint removal in accordance with an exemplary embodiment of the present disclosure;

FIG. 6 illustrates a flow diagram of a method of matching a first location attribute with a second location attribute of a breakpoint configured in a preset breakpoint storage container in an exemplary embodiment of the present disclosure;

FIG. 7 illustrates a flow diagram of a method of debugging code according to an interrupt mode in an example embodiment of the present disclosure;

FIG. 8 illustrates a flow diagram of a method of exposing script code for a breakpoint attachment in an exemplary embodiment of the present disclosure;

FIG. 9 illustrates a flow diagram of a method of pre-generating a local variable index table in an exemplary embodiment of the present disclosure;

FIG. 10 is a flow chart illustrating a method for determining index values corresponding to local variables based on a pre-generated local variable index table in an exemplary embodiment of the present disclosure;

FIG. 11 illustrates a flow diagram of a method of invoking a target script function during an interrupt in an exemplary embodiment of the present disclosure;

FIG. 12 is a flow diagram illustrating another script code debugging method in an exemplary embodiment of the present disclosure;

FIG. 13 is a schematic diagram showing the structure of a scripting language code debugging device in an exemplary embodiment of the present disclosure;

FIG. 14 illustrates a schematic diagram of a computer storage medium in an exemplary embodiment of the present disclosure; the method comprises the steps of,

fig. 15 shows a schematic structural diagram of an electronic device in an exemplary embodiment of the present disclosure.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. However, the exemplary embodiments may be embodied in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the example embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the present disclosure. One skilled in the relevant art will recognize, however, that the aspects of the disclosure may be practiced without one or more of the specific details, or with other methods, components, devices, steps, etc. In other instances, well-known technical solutions have not been shown or described in detail to avoid obscuring aspects of the present disclosure.

The terms "a," "an," "the," and "said" are used in this specification to denote the presence of one or more elements/components/etc.; the terms "comprising" and "having" are intended to be inclusive and mean that there may be additional elements/components/etc. in addition to the listed elements/components/etc.; the terms "first" and "second" and the like are used merely as labels, and are not intended to limit the number of their objects.

Furthermore, the drawings are merely schematic illustrations of the present disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and thus a repetitive description thereof will be omitted. Some of the block diagrams shown in the figures are functional entities and do not necessarily correspond to physically or logically separate entities.

The LPC language is a scripting language developed by Lars Pensj ǒ in 1989 from the C language, and is mainly used for developing MUD (Mutiple UserDimension, multi-role world) games.

As a scripting language, the compilation and execution of LPC code is done by its specialized engine drivers. Specifically, the compiling module of the engine driver firstly compiles the LPC script code into an opcode (operation code), and the function of the opcode is similar to the machine code generated after the compiling of the traditional compiling language, except that the traditional compiling language is executed on the CPU, and the LPC script code is executed in the virtual machine of the engine driver. The virtual machine module of the engine driving module circularly reads the next opcode and then executes different functions according to the meaning of the currently read opcode.

The writing of code inevitably generates errors, and when errors occur, a programmer needs to debug the code. The essence of debugging is the control, tracking, modification of the code execution process, with the most basic function being interruption.

The dynamic debugger for traditional compiled languages is well established, with the GDB tool being one of the most commonly used debugging tools. Debugging an LPC engine program written in the C language using GDB tools is easy, however, it is difficult if the GDB tools are used directly to debug LPC scripts executing in the virtual machines of the engine. Specifically, the process of executing the opcode by the virtual machine is equivalent to executing a large switch … case statement, and the execution positions in the virtual machine are the same no matter which line of the LPC file the current opcode belongs to, so when the breakpoint is set at the designated LPC file and line number by directly using the GDB tool, only the conditional breakpoint can be used, the breakpoint position is set before executing the opcode, and the breakpoint condition is set as the file to which the opcode corresponding to the breakpoint belongs and the line number to which the breakpoint belongs.

Meanwhile, the debugging means of the LPC script code provided by the authorities is an original printout debugging method, namely, a built-in function debug_ message (string msg) provided by an engine driver (the drivers of different versions of engines possibly have different built-in function names, but the functions are the same, and the character strings in the parameters are all output to a debug file), and required information is printed in a required place so as to achieve the purpose of debugging.

However, when code debugging is directly performed by using the existing GDB conditional breakpoint method, various debugging codes need to be manually inserted in different places, which is time-consuming and labor-consuming, meanwhile, the added debugging codes are easy to be confused with the original logic codes, and the added debugging codes need to be manually deleted, in addition, the debugging codes need to be recompiled and executed after being added, so that the debugging time is increased.

In addition, the code debugging is directly carried out by using the existing GDB conditional breakpoint mode, the time for waiting for interruption is long, and the debugging performance is seriously reduced. Specifically, most of conditional breakpoints need to perform conditional judgment on the GDB layer after the process being debugged is interrupted, if the condition is met, the interruption is maintained, and if the condition is not met, control right is returned to allow the process being debugged to continue running. When a condition breakpoint is carried out on a general process, the performance is not seriously affected, however, the place where the operation is executed by the virtual machine is frequently used, and if the condition breakpoint is set at the place, the process of the virtual machine frequently carries out the process of interrupt-condition judgment-continuous execution, thereby seriously affecting the debugging performance.

In an embodiment of the present disclosure, a method for debugging a scripting language code is provided first, which overcomes at least to some extent the drawbacks existing in the related art described above.

FIG. 1 shows a flow diagram of a scripting language code debugging method in an exemplary embodiment of the present disclosure, with reference to FIG. 1, the method includes:

step S110, acquiring a first position attribute of an operation code currently executed in a virtual machine, wherein the first position attribute comprises an identification of a target script code file to which the operation code belongs and position information of a script code corresponding to the operation code in the target script code file;

step S120, matching the first position attribute with a second position attribute of a breakpoint configured in a preset breakpoint storage container;

step S130, when the matching is successful, a preset breakpoint jump function is called to trigger a breakpoint debugging function at the operation code.

In the technical scheme provided by the embodiment shown in fig. 1, firstly, matching a first location attribute of an acquired operation code currently executed in a virtual machine with a second location attribute of a breakpoint configured in a preset breakpoint storage container; and then, when the matching is successful, calling a preset breakpoint jump function to trigger a breakpoint debugging function at the operation code. Compared with the related art, on one hand, in the method, the breakpoint in code debugging is configured in the preset breakpoint storage container, so that the efficiency of setting the breakpoint can be improved; on the other hand, the method and the device can avoid the influence of frequent interrupt-condition judgment-continuous execution process of the virtual machine process on code debugging performance in the related technology by matching the first position attribute of the operation code currently executed in the virtual machine with the second position attribute of the breakpoint configured in the preset breakpoint storage container so as to trigger the breakpoint debugging function, and improve the code debugging efficiency.

The following describes in detail the specific implementation of each step in the embodiment shown in fig. 1:

in step S110, a first location attribute of an opcode currently being executed in the virtual machine is acquired.

The script code in the present exemplary embodiment may include script code written in the LPC language. The virtual machine in step S110 may include a virtual machine in an engine driver corresponding to the LPC script code. Specifically, for the LPC script code, the compiling and executing are completed by the corresponding engine driver, the compiling module of the engine driver firstly compiles the LPC script code into opcodes, then the virtual machine module of the engine driver circularly reads an opcode, and different functions are executed according to the read opcodes so as to realize the logic of the LPC script code. The operation code currently executed in the virtual machine in step S110 may be understood as an opcode currently read by the virtual machine module in the engine driver corresponding to the LPC script code.

In an exemplary embodiment, the first location attribute of the opcode currently being executed in the virtual machine includes an identification of a target script code file to which the opcode belongs and location information of a script code corresponding to the opcode in the target script code file. The identification of the target script code file to which the operation code belongs may include a name of the target script code file to which the operation code belongs, and the location information of the script code corresponding to the operation code in the target script code file may include a line number of the script code corresponding to the operation code in the target script code file.

For example, if the script code a on line 5 of the LPC script code file 1 is compiled into an opcode1 (operation code 1) and the "eval_instrumentation" function in the virtual machine code intermediate. C obtains that the current opcode is opcode1, the first location attribute of opcode1 may be obtained as follows: line 5 of LPC script code file 1 indicates that the corresponding script code A of opcode1 is on line 5 of LPC script code file 1.

Next, in step S120, the first location attribute is matched with the second location attribute of the breakpoint configured in the preset breakpoint storage container.

In an exemplary embodiment, the preset breakpoint storage container may include a preset breakpoint storage array, and breakpoint data stored by each element in the preset breakpoint storage array includes a second location attribute of the breakpoint and a breakpoint state of the element.

The second location attribute of the breakpoint includes an identification of the script code file to which the breakpoint belongs and location information of the breakpoint in the script code file, for example, the second location attribute of the breakpoint may indicate what line of the script code file the breakpoint is configured in.

The breakpoint state of an element includes a first state in which no breakpoints are stored or in which stored breakpoints have been removed, a second state in which stored breakpoints are stored and in which stored breakpoints are invalid, and a third state in which stored breakpoints are valid. It will be appreciated that the breakpoint status of an element is used to indicate whether the element is currently available for storing breakpoint data. The breakpoint status of an element may also be used to indicate the status of breakpoint data stored in the element.

Specifically, when the breakpoint status of the element is the first status, it indicates that no breakpoint data is currently stored in the element or the stored breakpoint data has been removed, that is, it indicates that the element may be used to store the breakpoint data newly added by the user; when the breakpoint status of the element is the second status or the third status, the breakpoint data is stored in the element, and the breakpoint data cannot be used for storing other breakpoint data newly added by the user. When the breakpoint state of the element is the second state, the breakpoint data currently stored in the element is invalid, that is, the breakpoint debugging function is not triggered, and when the breakpoint state of the element is the third state, the breakpoint data currently stored in the element is valid, that is, the breakpoint debugging function is triggered.

For example, a global array may be defined for storing breakpoint information added by a user (such as a code debugger), that is, the preset breakpoint storage array. The size of the global array can be customized according to the requirement, for example, a global array including 10 elements is defined, and the size of the array meets the requirement of debugging breakpoint number, and the principle of not affecting the code running performance can be met. Each element of the global array may be a structure for storing breakpoint data, where the structure includes a file name, a line number, and a status flag. The state flag field includes 3 states, namely, the first state, the second state, and the third state, and the state in the structure of each element is marked as one of the first state, the second state, and the third state. For example, the state flag a indicates the first state, the state flag B indicates the second state, and the state flag C indicates the third state.

FIG. 2 is a diagram illustrating a memory structure of a preset breakpoint memory array in an exemplary embodiment of the present disclosure. Referring to fig. 2, 21 represents an element in a preset breakpoint storage array, and 22 represents breakpoint data stored in an element in the preset breakpoint storage array, including a breakpoint state of the element, a file name of a script code file to which the breakpoint belongs, and line number information of the breakpoint in the script code file.

It should be noted that, the initial state of the breakpoint state of each element in the preset breakpoint storage array is marked as the first state, i.e. the first state in which the breakpoint is not set.

For example, before breakpoint debugging is performed on the scripting language code, breakpoint data required during debugging can be added into the preset breakpoint storage array according to debugging requirements. Fig. 3 shows a flow diagram of a method of adding a breakpoint in an exemplary embodiment of the present disclosure. Referring to fig. 3, the method may include steps S310 to S320.

In step S310, in response to the instruction for adding the target breakpoint, elements in the preset breakpoint storage array are traversed according to an ascending order of index values of the elements.

In step S320, when traversing to an element whose breakpoint state is the first state, the second location attribute of the target breakpoint is stored in the current element, and the breakpoint state of the current element is reconfigured to the third state.

Furthermore, the user can remove unnecessary breakpoint data from the preset breakpoint storage array according to the requirement. Illustratively, FIG. 4 shows a flow diagram of a method of removing a breakpoint in an exemplary embodiment of the present disclosure. Referring to fig. 4, the method may include steps S410 to S420.

In step S410, in response to an operation instruction for removing the target breakpoint, the breakpoint state of the target element corresponding to the target breakpoint is reconfigured to the first state.

For example, the target breakpoint is stored in the 3 rd element of the preset breakpoint storage array, and in response to an operation instruction to remove the target breakpoint, the state of the 3 rd element of the preset breakpoint storage array may be reconfigured to the first state. While the second location attribute for the target breakpoint stored in element 3 that needs to be removed may or may not be deleted, the breakpoint state of element 3 needs to be configured to the first state.

In step S420, when there is an element to be adjusted whose breakpoint state is the second state or the third state after the target element corresponding to the target breakpoint, breakpoint data stored in the element to be adjusted is sequentially moved forward to a previous element corresponding to the element to be adjusted for storage.

In the preset breakpoint storage array, the index value of the element to be adjusted located behind the target element is larger than the index value of the target element. That is, the element to be adjusted may include an element in the preset breakpoint storage array having an index value greater than an index value of the target element corresponding to the target breakpoint.

It should be noted that if there is no element to be adjusted whose breakpoint state is the second state and the third state after the target element corresponding to the target breakpoint, the breakpoint state of the target element corresponding to the target breakpoint is only required to be reconfigured into the first state. The first state at this time may be understood as the current element stored the breakpoint but the stored breakpoint was removed.

Illustratively, FIG. 5 is a schematic diagram illustrating the state of a preset breakpoint storage array before and after breakpoint removal in an exemplary embodiment of the present disclosure. Referring to fig. 5, the breakpoint stored in the element 51 is a target breakpoint to be removed, i.e., the target breakpoint to be removed is "test.c:3", and the breakpoint data of the breakpoint is stored in the 3 rd element of the preset breakpoint storage array.

In the example of fig. 5, other breakpoint data is stored in the 4 th element and the 5 th element after the 3 rd element of the breakpoint storage array, that is, the breakpoint states of the 4 th element and the 5 th element are the second state or the third state, when the target breakpoint "test.c. 3" is removed, the breakpoint state of the 3 rd element may be reconfigured into the first state, then the breakpoint data stored in the 4 th element is moved forward to the 3 rd element for storage, and the breakpoint data stored in the 5 th element is moved forward to the 4 th element for storage.

When the breakpoint data is stored in the forward manner, the breakpoint state of the element in the breakpoint data is kept unchanged, for example, before the breakpoint data stored in the 4 th element is stored in the 3 rd element in the forward manner, the breakpoint state of the element stored in the 4 th element is in the second state, and after the forward manner, the breakpoint state of the element stored in the 3 rd element is still in the second state. That is, the first state of the 3 rd element that was previously reconfigured is replaced again by the breakpoint state of the element stored in the 4 th element.

Illustratively, the breakpoint state of an element in the preset breakpoint storage array may also be modified by a preset breakpoint state configuration instruction. The specific implementation modes of the method can be as follows:

responding to an invalid state configuration instruction aiming at a target breakpoint, and reconfiguring a breakpoint state of a target element corresponding to the target breakpoint into a second state in a preset breakpoint storage array;

and responding to an effective state configuration instruction aiming at the target breakpoint, resetting the breakpoint state of the target element corresponding to the target breakpoint into a third state in a preset breakpoint storage array.

For example, after a certain breakpoint is added in the preset array, the debugger temporarily does not need to use the breakpoint, and then the state of the element storing the breakpoint in the preset storage array can be configured into the second state through a preset breakpoint invalid state configuration instruction, and when the breakpoint needs to be used again, the state of the element storing the breakpoint in the preset storage array can be reconfigured into the third state through a preset breakpoint valid state configuration instruction.

Furthermore, the configured breakpoint data can be queried through a preset breakpoint data query instruction. The specific implementation modes of the method can be as follows:

and responding to the breakpoint query operation instruction, querying the breakpoint data stored in the preset breakpoint storage array, and displaying the queried breakpoint data on the client according to the first preset format.

In an exemplary embodiment, the first preset format may include displaying the queried breakpoint data at the client according to the identification of the script file to which the breakpoint belongs, the location information of the breakpoint in the script file to which the breakpoint belongs, and the order of the breakpoint states of the elements. The queried breakpoint data is displayed at the client, e.g., according to the format "test.c:7, b". Wherein B may be understood as a state flag of the second state pair, which indicates that a breakpoint is set on line 7 of the test.c. file, and the state of the current breakpoint is invalid.

For example, the breakpoint data operation function matched with the preset breakpoint array can be pre-written, so that the functions of adding a breakpoint, removing the breakpoint, invalidating or validating the breakpoint and checking the breakpoint are respectively realized.

As described above, the state flag a may indicate the first state, the state flag B may indicate the second state, and the state flag C may indicate the third state. When adding a breakpoint, the breakpoint data operation function can traverse a preset breakpoint data storage array until encountering an element with a state mark field A, adding the breakpoint and modifying the breakpoint state mark of the element into C; when a breakpoint is removed, the breakpoint data operation function can modify the breakpoint state mark of an element corresponding to the breakpoint into A and move all breakpoint data after the breakpoint forward by one; when the breakpoint is invalidated, the breakpoint data operation function can modify the breakpoint state mark of the element corresponding to the breakpoint into B; when the breakpoint is enabled to be effective, the breakpoint data operation function can modify the breakpoint state mark of the element corresponding to the breakpoint into C; when the breakpoint data is checked, the breakpoint data operation function can return the breakpoint data stored in the preset breakpoint storage array according to a first preset format.

Further, the breakpoint data operation function may be packaged as a breakpoint add instruction (break), a breakpoint remove instruction (delete), an invalid state setting instruction (disable), an valid state setting instruction (enable), and a breakpoint query instruction (info). Thus, code debugging personnel can conveniently call the breakpoint data operation function according to the corresponding instruction so as to realize the corresponding function.

After the breakpoint data is pre-configured in the preset breakpoint storage container, the first location attribute obtained in step S110 and the second location attribute of the breakpoint stored in the preset breakpoint storage container may be matched, so as to implement breakpoint debugging of the LPC scripting language code.

Fig. 6 is a flow diagram illustrating a method of matching a first location attribute with a second location attribute of a breakpoint configured in a preset breakpoint storage container in an exemplary embodiment of the present disclosure. Referring to fig. 6, the method may include steps S610 to S630. Wherein:

in step S610, elements in the preset breakpoint storage array are traversed according to the ascending order of the index values of the elements in the preset breakpoint storage array.

Wherein the index value of the element may include a subscript of the element.

In step S620, when traversing to the element whose stored second location attribute is the same as the first location attribute and whose breakpoint state is the third state, traversing is stopped and it is determined that the first location attribute matches successfully with the second location attribute of the breakpoint configured in the preset breakpoint storage container.

In step S630, when traversing to the element whose stored breakpoint state is the first state, traversing is stopped and it is determined that the matching between the first location attribute and the second location attribute of the breakpoint configured in the preset breakpoint container fails, so that the virtual machine continues to execute the next operation code.

For example, a section of code may be inserted before executing an opcode in the "eval_instrumentation" function of the virtual machine code of the LPC, where the function of the code is to traverse a preset breakpoint storage array, and once it is determined that the first location attribute of the current opcode is the same as the second location attribute stored in an element whose certain breakpoint state is the third state, it is determined that the matching is successful, that is, it is determined that the current opcode is a breakpoint, and this traversal may be stopped; upon encountering an element whose breakpoint state is the first state, determining that the matching fails, i.e., determining that the current opcode is not a breakpoint, and stopping traversing, while enabling the virtual machine to continue executing the next opcode.

In the disclosure, since the breakpoint adding and removing are implemented by the breakpoint adding method of the steps S310 to S320 and the breakpoint removing method of the steps S410 to S440, respectively, the breakpoint may be set in front of the array, and since the breakpoint state of the element is stored in the breakpoint data, when the traversal matching of the first position attribute and the second position attribute of the breakpoint is performed in the step S120, whether to continue the traversal may be determined according to the breakpoint state of the element, so that the traversal may be terminated in advance, the judging speed of the breakpoint may be improved, and further the efficiency and performance of the breakpoint debugging may be further improved.

Through step S110 and step S120, it can be determined whether the operation code currently executed in the virtual machine is a breakpoint. Further, when judging whether the operation code currently executed in the virtual machine is a breakpoint, the current interrupt mode can be also judged.

In an exemplary embodiment, the interrupt mode may include running to the next breakpoint (continuous), single step skip (next), single step entry (step), single step completion (finish).

For example, a global interrupt variable, such as a g_break_flag variable, may be defined, which has 4 values, where a value D represents that the interrupt is running to the next breakpoint (continuous), a value E represents that the interrupt is single step skip (next), a value F represents that the interrupt is single step enter (step), and a value G represents that the interrupt is single step complete (finish).

Meanwhile, a python script extended by the GDB may be written, four commands are respectively encapsulated continue, next, step, finish in the script, and when the four commands are encapsulated, the value of g_break_flag is changed into the value corresponding to each command, and then the continuous command of the GDB is executed, so as to return the execution right to the process of the virtual machine after the interrupt is implemented.

For example, when the interrupt mode is encapsulation of a command running to the next breakpoint, the value of g_break_flag may be taken as E, and then the continuation command of the GDB is executed. Thus, when the user inputs the continuous command, the current interrupt mode can be known to run to the next breakpoint, and after the breakpoint function is executed at the next breakpoint, the execution right can be returned to the process of the virtual machine by executing the continuous command of the GDB.

Exemplary, the specific embodiment of step S120 may be: and when the interrupt mode is running to the next breakpoint, matching the first position attribute with the second position attribute of the breakpoint configured in the preset breakpoint storage container.

Next, in step S130, when the matching is successful, a preset breakpoint jump function is invoked to trigger a breakpoint debug function at the opcode.

For example, when the interrupt mode is any one of single step skip, single step entry and single step completion, whether to execute the interrupt may be determined by simply determining a change in the call stack depth of the virtual machine.

Specifically, when the interrupt mode is single-step jump, if the current call stack depth of the virtual machine is not greater than the last call stack depth, a preset breakpoint jump function is called to trigger a breakpoint debugging function at the operation code;

It should be noted that, in the present disclosure, only when the interruption mode of the current breakpoint is running to the next breakpoint, the preset breakpoint storage container is traversed, so as to match the first location attribute with the second location attribute of the breakpoint configured in the preset breakpoint storage container. When the interruption mode of the breakpoint is single-step skip, single-step entry and single-step completion, the preset breakpoint storage container is not required to be traversed, and whether to execute the interruption is determined directly according to the change of the depth of the call stack.

FIG. 7 illustrates a flow diagram of a method of debugging code according to an interrupt mode in an example embodiment of the present disclosure. Referring to fig. 7, the method may include steps S710 to S780.

In step S710, a first location attribute of an operation code currently executed in the virtual machine is acquired;

In step S720, it is determined that the current interrupt mode is the current interrupt mode, when the current interrupt mode is running to the next breakpoint, step S730 is executed, when the current interrupt mode is single-step skip, step S740 is executed, when the current interrupt mode is single-step entry, step S750 is executed, and when the current interrupt mode is single-step completion, step S760 is executed.

In step S730, it is determined whether the first location attribute is matched with the second location attribute of the breakpoint configured in the preset breakpoint storage container, if so, step S770 is executed, and if not, step S780 is executed.

In step S740, it is determined whether the current call stack depth is less than or equal to the last call stack depth, if yes, step S770 is executed, and if no, step S780 is executed.

In step S750, it is determined whether the current call stack depth is greater than or equal to the last call stack depth, if yes, step S770 is executed, and if no, step S780 is executed.

In step S760, it is determined whether the current call stack depth is smaller than the last call stack depth, if yes, step S770 is executed, and if no, step S780 is executed.

In step S770, a preset breakpoint jump function is invoked to trigger a breakpoint debug function.

In step S780, execution of the next operation code is continued.

Through the steps S710 to S780 described above, the interrupt debug function in different manners can also be implemented. The call stack of the virtual machine may include a plurality of stack frames, and the call stack depth may be understood as the number of stack frames included in the call stack.

It should be noted that, in the call stack of the virtual machine, the call stack pointer csp points to the pointer at the top of the call stack, where the current address at the top of the call stack is stored, and the call stack pointer csp is also larger as the depth of the call stack is larger, so when the interrupt mode is any one of single step skip, single step entry, and single step completion, it is also possible to determine whether to execute the interrupt by determining the change of the call stack pointer csp of the virtual machine, and the technical term "call stack depth" in the step S710 to the step S780 is replaced by "call stack pointer csp".

Illustratively, the above script language code debugging method may further include: and responding to a preset code debugging instruction, starting a code debugging process, and adding a breakpoint debugging function at a preset breakpoint jump function to trigger the breakpoint debugging function when the preset breakpoint jump function is called.

The added breakpoint debug function may include a breakpoint debug function of the GDB itself. After the breakpoint debugging function is added at the preset breakpoint jump function, once the process of the virtual machine calls the preset breakpoint jump function, the added breakpoint debugging function can be triggered.

For example, a breakpoint jump function, such as debug_trigger (), may be written, the code within the function may be arbitrary, for example, the function may call debug_message (msg) to print out the information of interest, and the function may be used as a preset breakpoint jump function. Meanwhile, a python script of the GDB extension can also be written: and receiving user input in an infinite loop after the python script is started, and analyzing the user input as an instruction. Code debug instructions, such as encapsulated attach instructions, may be encapsulated in the python script, which may function as the preset code debug instructions described above, which function as: starting a code debugging process, automatically adding a breakpoint at a preset breakpoint jump function of 'debug_trigger', and automatically adding a breakpoint debugging function of the GDB at the preset breakpoint jump function, wherein once the process of the virtual machine calls the debug_trigger function, the breakpoint is triggered, namely the breakpoint debugging function of the GDB is triggered to realize breakpoint debugging of the script language code.

For example, script code near a breakpoint may also be exposed to a user when an interrupt occurs for convenient code debugging. Fig. 8 shows a flow diagram of a method of exposing script code for a breakpoint attachment in an exemplary embodiment of the present disclosure. Referring to fig. 8, the method may include steps S810 to S830. Wherein:

in step S810, if a preset breakpoint jump function triggers a breakpoint debug function, a first location attribute of the opcode is obtained;

in step S820, based on the first location attribute, a script code to be printed is read from a target script code file to which the operation code belongs;

in step S830, the script code corresponding to the operation code and the script code to be printed are displayed on the client according to the second preset format.

For example, in a Python script of a compiled GDB extension, a breakpoint processing function in the GDB may be registered through a GDB. For example, the script codes of the front and rear two lines of the line number where the script code corresponding to the current opcode is located are read and the printout is formatted.

The 7 th behavior example of the breakpoint triggered currently in the demo.c file can output the following print script code according to the second preset format:

“demo.c:7

5:{

6：int a＝101；

7：int b＝202；

8：int c＝a+b；

(LPC_GDB)”

wherein '5, 6, 7 and 8' in the codes are row numbers where script codes are located, and demo.c. 7 is a second position attribute of the set breakpoint.

Illustratively, after the breakpoint debug function is triggered at the opcode, the scripting language code debug method further comprises:

and in response to the modification instruction aiming at the target global variable value during the current interrupt, invoking a second preset function to deserialize the target global variable value in the modification instruction, and assigning the deserialized target global variable value to the target global variable.

For example, functions of printing variable values and importing variable values can be added in a virtual machine of script code to implement functions of viewing and modifying variable values accessible at breakpoints.

For example, for a global variable, a first preset function may be defined, and the name of the first preset function may be dump_global_value (char_name). The first preset function may return a serialized string of values of the global variable entered by the user, where the parameter name in the first preset function may represent the name of the global variable. Specifically, the first preset function may call a find_global_variable function in an object.c file of the virtual machine code of the LPC to query the value of the global variable input by the user, and call a save_variable_2 function in the object.c file of the virtual machine code of the LPC to serialize the queried value of the global variable.

Further, a second preset function may be defined, and the name of the second preset function may be restore_global_value (char_name). The second preset function may assign the value of the value string input by the user after the reverse serialization to the global variable corresponding to the name. Specifically, the second preset function may call a restore_svalue function in an object.c file in the virtual machine code of the LPC to deserialize the character string input by the user.

The serialization may be understood as converting the values of different types of variables stored in the virtual machine into a string type, and because of the LPC variable values stored in the virtual machine, there are various types including integer, string, array, dictionary, etc., when the values of these types of variables are presented to the user, they need to be serialized first and then converted into a string, and then printed into the display interface of the client; similarly, the values of the variables entered by the user are typically in the form of strings, and therefore, when modifying the values of different types of variables using the values of the string types entered by the user, it is necessary to deserialize the string into the corresponding variable type values.

Illustratively, after the operation code triggers the breakpoint debugging function, the script language code debugging method further comprises:

In response to a viewing instruction aiming at the target local variable value in the current interruption period, calling a third preset function to determine an index value of the target local variable based on a pre-generated local variable index table, inquiring the target local variable value corresponding to the target local variable according to the index value, and generating a second serialization character string of the target local variable value so as to display the second serialization character string on the client;

and calling a fourth preset function to deserialize the target local variable value in the modification instruction in response to the modification instruction aiming at the target local variable value in the current interrupt period, determining an index value corresponding to the target local variable based on a pre-generated local variable index table, and assigning the deserialized target local variable value to the corresponding target local variable according to the index value.

For example, for local variables, since the name of the local variable is not preserved after the LPC script code is compiled by the virtual machine, the local variable value may be viewed and modified by way of an index. The variable fp of the virtual machine code inter.c stores the start address of the current local variable, and the local variable value to be queried can be indexed through (fp+index), wherein index is the index value of the local variable and can be determined through a pre-generated index table of the local variable.

For the view of the value of the local variable, a third preset function may be defined, for example, the name of the third preset function may be dump_local_value_by_ index (int index), which may query the value of the local variable according to the index value index of the local variable input by the user, and return the serialized string of the value of the local variable. Likewise, the third preset function may call the save_variable_2 function in the object.c file of the virtual machine code of the LPC to serialize the value of the queried local variable.

For modification of the value of the local variable, a fourth preset function may be defined, for example, the name of the fourth function may be restore_local_value_by_index (int index, char) and the fourth preset function may assign the value of the value string after the reverse serialization to the local variable corresponding to the index. Likewise, the fourth preset function may call a restore_svalue function in an object.c file in the virtual machine code of the LPC to deserialize the value string input by the user.

Further, fig. 9 is a flowchart illustrating a method for generating a local variable index table in advance according to an exemplary embodiment of the present disclosure. Referring to fig. 9, the method may include steps S910 to S920.

In step S910, at the time of compiling the script code file, for each of the parsed local variable definitions, the identification of the script code file to which the local variable belongs, the identification of the function to which the local variable belongs, the positional information of the local variable, and the order in which the local variable is defined in the local variables included in the function are acquired.

Wherein the location information of the local variable comprises location information of the local variable definition in the script code file, e.g. the line number of the local variable definition in the script code file. The order in which the local variables are defined in the local variables included in the function may include what number of local variables are defined in the function to which the current local variable belongs.

Illustratively, in the process of debugging the script code file, an opcode corresponding to the script code file needs to be executed in the virtual machine, so the compiling module compiles the script code file to compile the script code into an opcode. When compiling the script code file, when analyzing the local variable definition place, the script code file name, function name, line number of the current local variable definition in the script code file and the number of the current local variable defined in the function to which the current local variable belongs can be obtained.

In step S920, in a local variable index table determined according to the identification of the script code file and the identification of the function, the identification of the local variable, the position information of the local variable, and the order in which the local variables are defined are stored to generate the local variable index table of the function.

For example, when a local variable is defined in a function, a layout variable index table of the function may be generated according to an identifier of a script code file to which the function belongs and an identifier of the function, and then, the identifier of each local variable defined in the function, position information of a defined place corresponding to each local variable, and a defined order corresponding to the local variable are stored in the local variable index table of the function, thereby generating the local variable index table of the function.

It should be noted that there may be local variables of the same name having different scopes in a function, and each local variable of the same name needs to store position information and defined order at its corresponding definition.

After the local variable index table of each function is generated, the local variable index table of each function may be stored. Therefore, after the breakpoint is triggered, the index value of the local variable which the user wants to inquire or modify can be determined according to the local variable index table of the function.

Illustratively, fig. 10 is a flowchart illustrating a method for determining index values corresponding to local variables based on a pre-generated local variable index table in an exemplary embodiment of the present disclosure. Referring to fig. 10, the method may include steps S1010 to S1040.

In step S1010, in response to a view instruction or a modification instruction for a target local variable value during the current interrupt, an identification of a target script code file to which the current breakpoint causing the current interrupt belongs and an identification of a target function are acquired to determine a local variable index table to be queried.

For example, during the current interrupt, a local variable index table determined by the identification of the script code file to which the current breakpoint causing the current interrupt belongs and the identification of the function to which the current breakpoint belongs may be used as the local variable index table to be queried.

In step S1020, in the local variable index table to be queried, the local variable to be queried, which is identical to the identification of the target local variable in the viewing instruction or the modification instruction and has the position information smaller than or equal to the position information of the current breakpoint in the target script code file, is determined.

Illustratively, during an interrupt, the local variable that needs to be modified or viewed is the local variable at or before the breakpoint, and therefore, it is necessary to determine, in the local variable index table to be queried, a local variable that is identical to the identification of the local variable in the corresponding instruction and whose location information is less than or equal to the location information of the current breakpoint in the script code file.

Next, in step S1030, it is determined that the local variable to be queried having the smallest difference between the position information and the position information of the current breakpoint in the object code file is the target local variable.

For example, as described above, in the same function, there may be homonymous local variables having different scopes due to being defined at different positions of the script code file, so in the local variable index table to be queried, a plurality of local variables to be queried may be determined, and the local variable closest to the current breakpoint may be determined as the target local variable.

In step S1040, according to the defined order corresponding to the target local variable, an index value corresponding to the target local variable in the view instruction or the modification instruction is determined.

In an exemplary embodiment, the defined order corresponding to the target local variable may be determined as the index value corresponding to the target local variable.

For example, after determining the index value corresponding to the local variable, for example, the index value is idex, the start address of the current target local variable is stored in the variable fp in the virtual machine code immediate.

For example, in the syntax analysis stage, when the local variable definition is analyzed, the LPC file name, the function name, the line number in the LPC file, and the order in which the currently defined local variable is defined in the corresponding function (i.e., the definition sequence number, which may represent the local variable in the function in which the local variable is located) can be obtained, and then a local variable index table file can be saved in the form of "file name+function name", and then the local variable name of the local variable, the line number in the LPC file, and the order defined in the corresponding function are added to the saved local variable index table file.

When the break point of the LPC script is triggered during dynamic debugging, the LPC file name, the function name and the line number of the LPC file to which the current break point belongs can be obtained in the virtual machine, at this time, when the value of a certain local variable needs to be modified or checked, the local variable index table corresponding to the LPC file name and the function name to which the current break point belongs can be found, the local variable with the same name as the local variable name needing to be modified or checked and the corresponding line number is smaller than or equal to the line number of the current break point, and the local variable with the minimum difference value between the corresponding line number and the line number of the current break point is the local variable to be queried or modified, the defined sequence corresponding to the local variable is taken as the index value index of the local variable, and then the value of the current target local variable can be indexed according to the above-mentioned (fp+index).

In an exemplary embodiment, a GDB extended python script may be written to encapsulate instructions to modify or view global or local variables for convenient user operation. Specifically, a lpc_file module may be written, and functions to parse the LPC script file, and parse the defined sequence of the local variables in each function, so as to generate a local variable index table in advance, so that the index value of the local variable to be queried or modified currently can be determined through the local variable index table.

Meanwhile, print, set, print _local and set_local commands can be packaged, and the print command and the set command respectively directly transmit variable names input by a user into a first preset function (such as the dump_global_value function) and a second preset function (such as the restore_global_value function) to realize the viewing and modification of global variables. The print_local command and the set_local command respectively convert variable names input by a user into corresponding index values through the lpc_file module, and then respectively transmit the index values into a third preset function (such as the dump_local_value_by_index function) and a fourth preset function (such as the restore_local_value_by_index function) so as to realize the checking and modification of local variables.

Further, after the breakpoint debug function is triggered at the opcode, the method further includes: and calling a fifth preset function to traverse a stack frame of the virtual machine in response to a viewing instruction of a call stack at the current breakpoint during the current interrupt to acquire call stack information at the current breakpoint, and displaying the call stack information at the current breakpoint at the client according to a third preset format.

The call stack information at the current breakpoint can be understood as a function call relationship at the current breakpoint. The source of the breakpoint function can be traced back through the call stack information at the current breakpoint, so that debugging personnel can debug codes more efficiently.

Illustratively, in the present disclosure, the call stack at the current breakpoint may be printed in the display interface of the client. Specifically, a fifth preset function may be defined, which functions to return call stack information at the current breakpoint of the LPC according to the third preset format.

For example, a fifth preset function "dump_backtrace ()" may be defined, whose function is to string the LPC call stack at the current breakpoint in a certain format and return. Specifically, the starting address of the call stack is stored in a variable control_stack in the virtual machine code inter.c of the LPC, csp is the address of the current stack top, each stack frame of the call stack contains the position information of the next function when the next function is called and the index of the next function in the function table of the next LPC file, so that the skip information of each function call can be obtained by traversing the stack frame, and then the obtained skip information of the function call is returned through a third preset format. For example, a piece of code in the demo.c file is as follows:

“1void test2()

2{

3int a＝10；

4}

5void test()

6{

7test2()

8}

9void create()

10{

11test()

12}”

Wherein, in the 12-row codes, the forefront number of each row of codes is the row number of the code, and the forefront number of each row of codes does not belong to the content of the code. If the breakpoint is triggered on line 11 of the code, in response to a view instruction for the call stack at the current breakpoint during the current interrupt, the following call stack information may be returned in a third preset format:

“call test2()at/demo.c：7

call test()at/demo.c：11”

the call stack information at the returned breakpoint may represent: the test () function is called at line 11 of the remove.c, and then the test2 () function is called again at line 7 of the remove.c in the test () function.

In an exemplary embodiment, an instruction of querying a call stack at a breakpoint may be encapsulated, for example, a fifth preset function is encapsulated as a "backtrace" instruction, and when the user inputs the "backtrace" instruction, the fifth preset function may be invoked to realize printout of the call stack at the current breakpoint.

Further, after the breakpoint debugging function is triggered at the operation code, the script language code debugging method further comprises:

and calling a sixth preset function to execute the target script function in response to a calling instruction aiming at the target script function during the current interrupt.

By way of example, FIG. 11 illustrates a flow diagram of a method of invoking a target script function during an interrupt in an exemplary embodiment of the present disclosure. Referring to fig. 11, the method may include steps S1110 to S1140. Wherein:

In step S1110, the identifier of the script file to which the target script function belongs, the identifier of the target script function, and the value of at least one call parameter included in the call instruction are moved to the stack top of the runtime stack of the virtual machine.

For example, the identifier of the script file to which the target script function belongs, the identifier of the target script function, and the value of at least one call parameter input by the user may be moved to the stack top of the runtime stack of the virtual machine by calling the built-in function "push_svalue" of the virtual machine.

In step S1120, the target script function is executed based on the identification of the script file in the stack top of the runtime stack, the identification of the target script function, and the value of the call parameter, and the return value of the target script function is stored in the stack top of the runtime stack.

For example, a built-in function "f_call_other" of the virtual machine may be called, a value in the runtime stack is regarded as an identifier of a script code file to be called, an identifier of a function, and a value of a parameter, then a corresponding function in a corresponding script code file is called according to the identifier of the script code file and the identifier of the function, and the value of the parameter, and a return value of the function is stored at the stack top of the runtime stack.

Next, in step S1130, the return value of the target script function is acquired from the stack top of the runtime stack and output.

For example, the virtual machine may obtain the return value of the target script function from the top of the runtime stack and print out the return value in the display interface of the client.

In step S1140, the top of the runtime stack is restored to the state before the target script function is executed.

For example, after the target script function is executed, a built-in function "pop_stack" of the virtual machine may be called to restore the runtime stack to a state prior to executing the target script function. Thus, the execution and the calling of the target script function during the interrupt can be realized without influencing the subsequent debugging process.

For example, a sixth preset function may be predefined, where the name of the sixth preset function may be "call_debuger_func", and the corresponding sixth preset function may be in the form of "call_debuger_func (char_filename, int numark, …)". Specifically, the first 3 parameters are the file name of the script code file to which the target script function to be executed belongs, the function name of the target script function to be executed, and the number to be transmitted, and the last "…" is a variable length parameter, where the variable length parameter indicates that numark strings can be transmitted, and each string can be inversely sequenced to a parameter value. The function of the sixth preset function is to execute the target script function in the target script file specified by the user once, and the return value of the target script function is used as the return value of the sixth preset function. The implementation process of the sixth preset function may be: firstly, a built-in function 'push_svalue' of the virtual machine is called to move an incoming 'filename, funcname' and a plurality of parameter values (namely, parameter values of which the incoming numark character strings are inversely sequenced) into the stack top of a runtime stack, then a built-in function 'f_call_other' in the virtual machine is called, and finally the stack top of the runtime stack of a built-in function 'pop_stack' in the virtual machine is called to restore to a state before a target script function is executed.

The function of the f_call_other function is to consider several values in the runtime stack as the LPC file name, function name and parameter value to be called and executed, then call the corresponding function in the corresponding LPC file, and put the return value of the function to the stack top for the call to take.

FIG. 12 illustrates a flow diagram of another script code debugging method in an exemplary embodiment of the present disclosure. Referring to fig. 12, the method may include steps S1210 to S1260. Wherein:

in step S1210, a first location attribute of an opcode currently being executed in a virtual machine is acquired. The description of the first location attribute in step S1210 may refer to the description of the first location attribute in step S110 described above.

In step S1220, the preset breakpoint storage array is traversed, and the first location attribute is matched with the second location attribute of the breakpoint in the preset breakpoint storage array.

In step S1230, it is determined whether a breakpoint is set at the current operation code, if yes, the process goes to step S1240, otherwise, the process goes to step S1250.

Illustratively, when the first location attribute is the same as the second location attribute of the breakpoint in the preset breakpoint storage array, determining that the breakpoint is set at the current opcode, otherwise, not setting the breakpoint at the current opcode.

In step S1240, it is determined whether the breakpoint set at the current opcode is valid, if so, the process goes to step S1260, otherwise the process goes to step S1250.

For example, whether a breakpoint set at a current opcode is effective may be determined based on a breakpoint state of an element in a preset breakpoint storage array. The second state is inactive, and the third state is active.

In step S1250, execution of the next operation code continues.

In step S1260, the preset breakpoint debug function is invoked to implement an interrupt at the current opcode.

According to the embodiment of the disclosure, through the transformation of the virtual machine program, the trigger for judging the breakpoint can be adjusted from the conditional breakpoint mode of the GDB to be directly carried out in the virtual machine, so that the consumption of frequent interruption is avoided, the running performance in the debugging process is greatly improved, and the efficiency of dynamic debugging of the LPC script language code is improved.

Further, because in the preset breakpoint array, the set breakpoints are stored in the elements in front of the preset breakpoint storage array, namely, the set breakpoints are stored in the elements with small index values, when traversing the preset breakpoint array according to the ascending order of the index values, once traversing to the elements without the set breakpoints or the elements with the set breakpoints removed, the traversing can be directly stopped, so that the preset breakpoint storage array is not necessarily completely traversed, and the performance and the efficiency of breakpoint debugging are further improved.

Meanwhile, the mapping relation between the local variable names and the corresponding index values in each function or module of each LPC file is stored in the local variable index table during compiling, so that the corresponding local variables can be automatically indexed according to the local variable names input by a user, the process that the user manually calculates the index values of the local variables is avoided, the use threshold for debugging LPC script codes in a virtual machine is reduced, and the breakpoint debugging efficiency is further improved.

The functions of checking and modifying accessible variable values at break points, printing call stacks at the current break points of LPC, executing any appointed script function during interruption and further facilitating efficient debugging of LPC script codes by using GDB tools by users can be realized through related preset functions and corresponding packaging instructions.

Those skilled in the art will appreciate that all or part of the steps implementing the above embodiments are implemented as a computer program executed by a CPU. When executed by a CPU, performs the functions defined by the above-described method provided by the present invention. The program may be stored in a computer readable storage medium, which may be a read-only memory, a magnetic disk or an optical disk, etc.

Furthermore, it should be noted that the above-described figures are merely illustrative of the processes involved in the method according to the exemplary embodiment of the present invention, and are not intended to be limiting. It will be readily appreciated that the processes shown in the above figures do not indicate or limit the temporal order of these processes. In addition, it is also readily understood that these processes may be performed synchronously or asynchronously, for example, among a plurality of modules.

Fig. 13 is a schematic diagram showing a configuration of a scripting language code debugging apparatus in an exemplary embodiment of the present disclosure. Referring to fig. 13, the script language code debugging apparatus 1300 may include a first location attribute acquiring module 1310, a location attribute matching module 1320, and a breakpoint debugging function triggering module 1330.

A first location attribute obtaining module 1310 configured to obtain a first location attribute of an operation code currently executed in a virtual machine, where the first location attribute includes an identifier of a target script code file to which the operation code belongs and location information of a script code corresponding to the operation code in the target script code file;

a location attribute matching module 1320 configured to match the first location attribute with a second location attribute of a breakpoint configured in a preset breakpoint storage container;

The breakpoint debug function trigger module 1330 is configured to call a preset breakpoint jump function to trigger the breakpoint debug function at the opcode when the matching is successful.

In an exemplary implementation of the disclosure, based on the foregoing embodiment, the preset breakpoint storage container includes a preset breakpoint storage array, where breakpoint data stored by each element in the preset breakpoint storage array includes a second location attribute of the breakpoint and a breakpoint state of the element;

In an exemplary implementation of the present disclosure, based on the foregoing embodiment, the scripting language code debugging device 1300 may further include a breakpoint adding module and a breakpoint removing module, where:

the breakpoint adding module is configured to respond to an operation instruction for adding a target breakpoint, traverse the elements in the preset breakpoint storage array according to the ascending order of index values of the elements, store the second position attribute of the target breakpoint into the elements when traversing to the elements with the breakpoint states being the first state, and reconfigure the breakpoint states of the elements to be the third state;

The breakpoint removing module is configured to reconfigure a breakpoint state of a target element corresponding to a target breakpoint into a first state in response to an operation instruction for removing the target breakpoint, and sequentially forward breakpoint data stored in the element to be adjusted to a previous element corresponding to the element to be adjusted for the element to be adjusted to be stored when the element to be adjusted with the breakpoint state being a second state or a third state exists after the target element corresponding to the target breakpoint;

In an exemplary implementation manner of the present disclosure, based on the foregoing embodiment, the script language code debugging device 1300 may further include a breakpoint invalidation module, a breakpoint validity module, and a breakpoint query module, where:

the breakpoint invalidation module is configured to reconfigure a breakpoint state of a target element corresponding to a target breakpoint to a second state in the preset breakpoint storage array in response to an invalidation state configuration instruction for the target breakpoint;

the breakpoint effective module is configured to reconfigure a breakpoint state of a target element corresponding to a target breakpoint to a third state in the preset breakpoint storage array in response to an effective state configuration instruction for the target breakpoint;

The breakpoint query module is configured to respond to a breakpoint query operation instruction, query the breakpoint data stored in the preset breakpoint storage array, and display the queried breakpoint data on the client according to a first preset format.

In an exemplary implementation of the present disclosure, based on the foregoing embodiment, the location attribute matching module 1320 described above is further specifically configured to:

stopping traversing and determining that the first position attribute is successfully matched with the second position attribute of the breakpoint configured in the preset breakpoint storage container when traversing to the element with the second position attribute being the same as the first position attribute and the breakpoint state being the third state;

In an exemplary implementation of the present disclosure, based on the foregoing embodiment, the scripting language code debugging device 1300 further includes an interrupt mode determination module configured to:

In an exemplary implementation of the present disclosure, based on the foregoing embodiment, the scripting language code debugging device 1300 further includes a breakpoint function pre-adding module, where the module is specifically configured to:

In an exemplary implementation of the present disclosure, based on the foregoing embodiment, the scripting language code debugging device 1300 further includes a breakpoint code printing module configured to:

In an exemplary implementation of the present disclosure, based on the foregoing embodiment, the scripting language code debugging device 1300 further includes a global variable access module specifically configured to:

In an exemplary implementation of the present disclosure, based on the foregoing embodiment, the scripting language code debugging device 1300 further includes a local variable access module specifically configured to:

In an exemplary implementation of the present disclosure, based on the foregoing embodiment, the local variable index table is generated in advance by:

in an exemplary implementation manner of the present disclosure, based on the foregoing embodiment, the determining, based on a pre-generated local variable index table, an index value corresponding to a target local variable includes:

In one exemplary implementation of the present disclosure, based on the foregoing embodiment, the scripting language code debugging apparatus 1300 further includes a call stack information viewing module configured to:

In an exemplary implementation of the present disclosure, based on the foregoing embodiment, the scripting language code debugging device 1300 further includes a target scripting function execution module configured to:

The specific details of each unit in the above-mentioned scripting language code debugging device have been described in detail in the corresponding scripting language code debugging method, so that the details are not repeated here.

It should be noted that although in the above detailed description several modules or units of a device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit in accordance with embodiments of the present disclosure. Conversely, the features and functions of one module or unit described above may be further divided into a plurality of modules or units to be embodied.

Furthermore, although the steps of the methods in the present disclosure are depicted in a particular order in the drawings, this does not require or imply that the steps must be performed in that particular order or that all illustrated steps be performed in order to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step to perform, and/or one step decomposed into multiple steps to perform, etc.

From the above description of embodiments, those skilled in the art will readily appreciate that the example embodiments described herein may be implemented in software, or may be implemented in software in combination with the necessary hardware. Thus, the technical solution according to the embodiments of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (may be a CD-ROM, a U-disk, a mobile hard disk, etc.) or on a network, including several instructions to cause a computing device (may be a personal computer, a server, a mobile terminal, or a network device, etc.) to perform the method according to the embodiments of the present disclosure.

In an exemplary embodiment of the present disclosure, a computer storage medium capable of implementing the above method is also provided. On which a program product is stored which enables the implementation of the method described above in the present specification. In some possible embodiments, the various aspects of the present disclosure may also be implemented in the form of a program product comprising program code for causing a terminal device to carry out the steps according to the various exemplary embodiments of the disclosure as described in the "exemplary methods" section of this specification, when the program product is run on the terminal device.

Referring to fig. 14, a program product 1400 for implementing the above-described method according to an embodiment of the present disclosure is described, which may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may be run on a terminal device, such as a personal computer. However, the program product of the present disclosure is not limited thereto, and in this document, a readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium would include the following: an electrical connection having one or more wires, a portable disk, a hard disk, random Access Memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

The computer readable signal medium may include a data signal propagated in baseband or as part of a carrier wave with readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A readable signal medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Program code for carrying out operations of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device, partly on a remote computing device, or entirely on the remote computing device or server. In the case of remote computing devices, the remote computing device may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computing device (e.g., connected via the Internet using an Internet service provider).

In addition, in an exemplary embodiment of the present disclosure, an electronic device capable of implementing the above method is also provided.

Those skilled in the art will appreciate that the various aspects of the present disclosure may be implemented as a system, method, or program product. Accordingly, various aspects of the disclosure may be embodied in the following forms, namely: an entirely hardware embodiment, an entirely software embodiment (including firmware, micro-code, etc.) or an embodiment combining hardware and software aspects may be referred to herein as a "circuit," module "or" system.

An electronic device 1500 according to such an embodiment of the present disclosure is described below with reference to fig. 15. The electronic device 1500 shown in fig. 15 is merely an example and should not be construed to limit the functionality and scope of use of embodiments of the present disclosure in any way.

As shown in fig. 15, the electronic device 1500 is embodied in the form of a general purpose computing device. The components of electronic device 1500 may include, but are not limited to: the at least one processing unit 1510, the at least one storage unit 1520, a bus 1530 connecting the different system components (including the storage unit 1520 and the processing unit 1510), and a display unit 1540.

Wherein the storage unit stores program code that is executable by the processing unit 1510 such that the processing unit 1510 performs steps according to various exemplary embodiments of the present disclosure described in the above section of the "exemplary method" of the present specification. For example, the processing unit 1510 may perform the steps as shown in fig. 1: step S110, acquiring a first position attribute of an operation code currently executed in a virtual machine; step S120, matching the first position attribute with a second position attribute of a breakpoint configured in a preset breakpoint storage container; step S130, when the matching is successful, a preset breakpoint jump function is called to trigger a breakpoint debugging function at the operation code.

Also, the processing unit 1510 may perform steps in the methods shown in fig. 3, 4, and 6 to 12.

The storage unit 1520 may include readable media in the form of volatile memory units such as Random Access Memory (RAM) 15201 and/or cache memory 15202, and may further include Read Only Memory (ROM) 15203.

The storage unit 1520 may also include a program/utility 15204 having a set (at least one) of program modules 15205, such program modules 15205 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of which may include an implementation of a network environment.

Bus 1530 may be a bus representing one or more of several types of bus structures including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

The electronic device 1500 may also communicate with one or more external devices 1600 (e.g., keyboard, pointing device, bluetooth device, etc.), one or more devices that enable a user to interact with the electronic device 1500, and/or any device (e.g., router, modem, etc.) that enables the electronic device 1500 to communicate with one or more other computing devices. Such communication may occur through an input/output (I/O) interface 1550. Also, the electronic device 1500 may also communicate with one or more networks such as a Local Area Network (LAN), a Wide Area Network (WAN) and/or a public network, for example, the Internet, through a network adapter 1560. As shown, the network adapter 1560 communicates with other modules of the electronic device 1500 over the bus 1530. It should be appreciated that although not shown, other hardware and/or software modules may be used in connection with electronic device 1500, including, but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, data backup storage systems, and the like.

From the above description of embodiments, those skilled in the art will readily appreciate that the example embodiments described herein may be implemented in software, or may be implemented in software in combination with the necessary hardware. Thus, the technical solution according to the embodiments of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (may be a CD-ROM, a U-disk, a mobile hard disk, etc.) or on a network, including several instructions to cause a computing device (may be a personal computer, a server, a terminal device, or a network device, etc.) to perform the method according to the embodiments of the present disclosure.

Furthermore, the above-described figures are only schematic illustrations of processes included in the method according to the exemplary embodiments of the present disclosure, and are not intended to be limiting. It will be readily appreciated that the processes shown in the above figures do not indicate or limit the temporal order of these processes. In addition, it is also readily understood that these processes may be performed synchronously or asynchronously, for example, among a plurality of modules.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any adaptations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

Claims

1. A script language code debugging method, comprising:

when the interrupt mode is running to the next breakpoint, matching the first position attribute with a second position attribute of a breakpoint configured in a preset breakpoint storage container;

when the matching is successful, a preset breakpoint jump function is called to trigger a breakpoint debugging function at the operation code;

the method further comprises the steps of:

when the interrupt mode is single-step jump, if the current call stack depth of the virtual machine is not greater than the last call stack depth, a preset breakpoint jump function is called to trigger a breakpoint debugging function at the operation code;

when the interrupt mode is single-step entry, if the current call stack depth of the virtual machine is not smaller than the last call stack depth, calling a preset breakpoint jump function to trigger a breakpoint debugging function at the operation code;

2. The script language code debugging method according to claim 1, wherein the preset breakpoint storage container comprises a preset breakpoint storage array, and the breakpoint data stored by each element in the preset breakpoint storage array comprises a second location attribute of the breakpoint and a breakpoint state of the element;

3. The scripting language code debugging method according to claim 2, wherein the method further comprises:

4. A scripting language code according to claim 3, characterised in that the method further comprises:

5. A scripting language code according to claim 3, wherein said matching the first location attribute with a second location attribute of a breakpoint configured in a preset breakpoint storage container comprises:

6. The scripting language code debugging method according to claim 5, wherein the method further comprises:

7. The scripting language code debugging method according to claim 1, wherein the method further comprises:

8. The scripting language code debugging method according to any one of claims 1 to 7, further comprising:

9. The scripting language code debugging method according to claim 1, wherein after triggering a breakpoint debugging function at the opcode, the method further comprises:

10. The scripting language code debugging method according to claim 1, wherein after triggering a breakpoint debugging function at the opcode, the method further comprises:

11. The script language code debugging method of claim 10, wherein the local variable index table is generated in advance by:

Wherein the location information of the local variable comprises location information of the local variable definition in the script code file.

12. The script language code debugging method of claim 11, wherein the determining an index value corresponding to a target local variable based on a pre-generated local variable index table comprises:

13. The scripting language code debugging method according to claim 1, wherein after triggering a breakpoint debugging function at the opcode, the method further comprises:

14. The scripting language code debugging method according to claim 1, wherein after triggering a breakpoint debugging function at the opcode, the method further comprises:

15. A scripting language code debugging device, comprising:

the position attribute matching module is configured to match the first position attribute with a second position attribute of a breakpoint configured in a preset breakpoint storage container when the interrupt mode is running to the next breakpoint;

the breakpoint debugging function triggering module is configured to call a preset breakpoint jump function to trigger the breakpoint debugging function at the operation code when the matching is successful;

the apparatus is further configured to: when the interrupt mode is single-step jump, if the current call stack depth of the virtual machine is not greater than the last call stack depth, a preset breakpoint jump function is called to trigger a breakpoint debugging function at the operation code; when the interrupt mode is single-step entry, if the current call stack depth of the virtual machine is not smaller than the last call stack depth, calling a preset breakpoint jump function to trigger a breakpoint debugging function at the operation code; when the interrupt mode is single-step completion, if the current call stack depth of the virtual machine is smaller than the last call stack depth, a preset breakpoint jump function is called to trigger a breakpoint debugging function at the operation code.

16. A computer readable storage medium, on which a computer program is stored, characterized in that the program, when being executed by a processor, implements the method of any one of claims 1 to 14.

17. An electronic device, comprising:

one or more processors;

storage means for storing one or more programs which, when executed by the one or more processors, cause the one or more processors to implement the method of any of claims 1 to 14.