CN113342654A

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

Info

Publication number: CN113342654A
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: 2021-09-03
Anticipated expiration: 2041-06-08
Also published as: CN113342654B

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 an electronic device. Wherein, the method comprises the following steps: acquiring a first position attribute of an operation code executed in a virtual machine at present, wherein the first position attribute comprises an identifier 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 debugging efficiency of the script language code can be improved based on the configuration of the position attribute of the 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 technologies, and in particular, to a scripting language code debugging method, a scripting language code debugging apparatus, a computer-readable storage medium, and an electronic device.

Background

The LPC language (programming language developed by Lars Pensj ǒ) is a scripting language developed on the basis of the syntax of the C language. As a scripting language, the compilation and execution of LPC code is implemented by its specialized engine driver. Writing of code inevitably generates errors, and programmers need to debug the code when the errors occur.

In the related art, a GDB tool (GDB is a program debugging 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 a GDB is used 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 method requires manual addition of breakpoint setting code, and after debugging is completed, the added debugging code needs to be manually deleted to prevent confusion with the original code, thereby greatly reducing the debugging efficiency of LPC code.

It is to be noted that the information disclosed in the above background section is only for enhancement of 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 present disclosure is directed to a method and an apparatus for debugging scripting language codes, a computer-readable storage medium, and an electronic device, so as to overcome, at least to some extent, the problem of low efficiency in debugging scripting language codes by directly using a GDB tool in the related art.

Additional features and advantages of the disclosure will be set forth in the detailed description which follows, or in part will be obvious from the description, or may be learned by practice of the disclosure.

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

acquiring a first position attribute of an operation code executed in a virtual machine at present, wherein the first position attribute comprises an identifier 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 scheme, the preset breakpoint storage container includes a preset breakpoint storage array, where the breakpoint data stored in each element in the preset breakpoint storage array includes a second position attribute of the breakpoint and a breakpoint status of the element;

the second position attribute of the breakpoint comprises an identifier 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 elements include a first state in which no breakpoint is stored or a stored breakpoint has been removed, a second state in which a breakpoint has been stored and the stored breakpoint is invalid, and a third state in which a breakpoint has been stored and the stored breakpoint is valid.

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

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

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

in the preset breakpoint storage array, the index value of the element to be adjusted located behind the target element is greater than the index value of the target element.

responding to an invalid state configuration instruction aiming at a target breakpoint, and reconfiguring the 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 the 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 at the client according to a first preset format.

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

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

and when the stored second position attribute is traversed to be the same as the first position attribute and the breakpoint state is the element of the third state, 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.

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

and when the interruption mode is to be operated to the next breakpoint, matching the first position attribute with a second position attribute of the breakpoint configured in the preset breakpoint storage container.

when the interruption 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;

and when the interruption mode is single step completion, if the current call stack depth of the virtual machine is less than the last call stack depth, calling a preset breakpoint jump function to trigger a breakpoint debugging function at the operation code.

responding to a preset code debugging instruction, starting a code debugging process, and adding a breakpoint debugging function at a preset breakpoint jump function so as 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, acquiring a first position attribute of the operation code;

reading script codes to be printed in a target script code file to which the operation codes belong based on the first position attribute;

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

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

In an exemplary embodiment of the present disclosure, based on the foregoing scheme, after the breakpoint debugging function is triggered at the opcode, the method further includes:

in response to a view instruction for a target global variable value during a current interrupt, invoking a first preset function to query the target global variable value and generate a first serialized string of the target global variable value to display the first serialized string at a client;

and in response to a modification instruction aiming at the target global variable value during the current interrupt, calling a second preset function to perform deserialization on 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 viewing instruction aiming at a target local variable value during the current interruption, calling a third preset function to determine an index value of the target local variable based on a local variable index table generated in advance, inquiring a 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 a client;

and responding to a modification instruction aiming at the target local variable value in the current interrupt period, calling a fourth preset function to perform deserialization on the target local variable value in the modification instruction, determining an index value corresponding to the target local variable based on a local variable index table generated in advance, 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 the script code file is compiled, aiming at each analyzed local variable definition, acquiring an identifier of the script code file to which the local variable belongs, an identifier of a function to which the local variable belongs, position information of the local variable and a sequence of the local variable defined 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 a 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 scheme, the determining an index value corresponding to a target local variable based on a pre-generated local variable index table includes:

in response to a viewing instruction or a modifying instruction aiming at a target local variable value in the current interruption period, acquiring an identifier of a target script code file and an identifier of a target function, wherein the target script code file and the identifier of the target function belong to a current breakpoint causing the current interruption, so as to determine a local variable index table to be inquired;

in the local variable index table to be queried, determining a local variable to be queried which has the same identifier as a target local variable in the viewing instruction or the modifying instruction and has position information less than or equal to the position information of the current breakpoint in the target script code file;

determining a local variable to be inquired 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 viewing instruction or the modifying instruction according to the defined sequence corresponding to the target local variable.

and in response to a viewing instruction aiming at the call stack at the current breakpoint during the current interrupt, calling a fifth preset function to traverse the stack frame of the virtual machine so as to acquire the 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.

responding to a calling instruction aiming at the target script function during the current interruption, calling a sixth preset function to execute the target script function;

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

moving the mark of the script file to which the target script function belongs, the mark 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 and outputting the return value;

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

According to a second aspect of the present disclosure, there is provided a script language code debugging apparatus, including:

the first position attribute acquisition module is configured to acquire a first position attribute of an operation code currently executed in a virtual machine, wherein the first position attribute comprises an identifier 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;

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 as described in the first aspect of the above embodiments.

According to a fourth aspect of the embodiments of the present disclosure, there is provided an electronic apparatus including: a processor; and a storage device 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 as described in the first aspect of the embodiments above.

As can be seen from the foregoing technical solutions, the script language code debugging method, the script language code debugging apparatus, 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 obtained currently executed opcode in a virtual machine is matched 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, the breakpoint in the preset breakpoint storage container configuration code debugging can improve the breakpoint setting efficiency; on the other hand, the first position attribute of the currently executed operation code in the virtual machine is matched with the second position attribute of the breakpoint configured in the preset breakpoint storage container to trigger the breakpoint debugging function, so that the influence of the frequent process of 'interruption-condition judgment-continuous execution' of the virtual machine process in the related art on the code debugging performance can be avoided, and the code debugging efficiency is improved.

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 present disclosure and together with the description, serve to explain the principles of the disclosure. It is to be understood that the drawings in the following description are merely exemplary of the disclosure, and that other drawings may be derived from those drawings by one of ordinary skill in the art without the exercise of inventive faculty.

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

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

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

FIG. 4 illustrates a flow diagram of a method for removing breakpoints 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 an exemplary embodiment of the present disclosure;

FIG. 6 is a flowchart illustrating a method for 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 is a flow diagram illustrating a method for debugging code in accordance with an interrupt approach in an example embodiment of the present disclosure;

FIG. 8 is a flowchart illustrating a method of exposing script code for a breakpoint attachment in an exemplary embodiment of the present disclosure;

FIG. 9 is a flowchart illustrating a method of pre-generating a local variable index table in an exemplary embodiment of the disclosure;

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

FIG. 11 is a flowchart illustrating a method of making a call to a target script function during an interrupt in an exemplary embodiment of the present disclosure;

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

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

FIG. 14 shows a schematic diagram of a structure of a computer storage medium in an exemplary embodiment of the disclosure; and the number of the first and second groups,

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. Example embodiments may, however, be embodied in many different 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 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 disclosure. One skilled in the relevant art will recognize, however, that the subject matter of the present disclosure can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and the like. 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/parts/etc.; the terms "comprising" and "having" are intended to be inclusive and mean that there may be additional elements/components/etc. other than the listed elements/components/etc.; the terms "first" and "second", etc. are used merely as labels, and are not limiting on 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 their repetitive description 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 script language developed by Lars Pensj ǒ in 1989 according to the C language, and is mainly used for developing MUD (multiple user dimension) games.

As a scripting language, the compilation and execution of LPC code is done by its specialized engine driver. Specifically, the engine driver compiling module first compiles the LPC script code into an opcode (operation code), which has a function similar to that of a machine code generated by compiling a conventional compilation language, except that the conventional compilation 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 opcode which is currently read in.

The writing of code inevitably generates errors, and programmers need to debug the code when the errors occur. The essence of debugging is the control, tracking, modification of the code execution process, where the most basic function is interruption.

Dynamic debuggers for traditional compiled languages are well established, and the GDB tool is one of the most commonly used debugging tools. The LPC engine program written in C language is easy to debug using GDB tool, however it is very difficult if the LPC script executed in the virtual machine of the engine is debugged directly using GDB tool. Specifically, the process of executing the opcode by the virtual machine is equivalent to the process of executing a large "switch … case" statement, and the execution position in the virtual machine is the same no matter which line of which LPC file the current opcode belongs to, so that when the GDB tool is directly used to set a breakpoint at a specified LPC file and line number, only conditional breakpoints can be used, and the breakpoint position is set before the opcode is executed, 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 official is the original printing output debugging method, that is, the built-in function debug _ message (string msg) provided by the engine driver is used (the drivers of the engines of different versions may have different built-in function names, but the functions are the same, and all the functions are to output the character strings in the parameters to the debug file), and the required information is printed at the required place, so as to achieve the purpose of debugging.

However, when the existing GDB conditional breakpoint manner is directly used for code debugging, various debugging codes need to be manually inserted into different places, which is time-consuming and labor-consuming, and meanwhile, the added debugging codes are easily confused with the original logic codes, and the debugging codes need to be manually deleted after being added.

In addition, the existing GDB conditional breakpoint mode is directly used for code debugging, the time for waiting for interruption is long, and the debugging performance is seriously reduced. Specifically, most conditional breakpoints require that the process being debugged is subjected to condition judgment on the layer GDB after being interrupted, and if the conditions are met, the process is maintained to be interrupted, and if the conditions are not met, the process being debugged is handed back to the control right to continue running. When the condition breakpoint is performed on the general process, the performance is not seriously affected, however, the space where the virtual machine executes the opcode is frequently used, and if the condition breakpoint is set at the place, the process of the virtual machine frequently performs the process of 'interrupt-condition judgment-continuous execution', so that the debugging performance is seriously affected.

In an embodiment of the present disclosure, a method for debugging scripting language code is provided, which overcomes at least some of the above-mentioned shortcomings in the related art.

Fig. 1 is a flowchart illustrating a method for debugging a scripting language code in an exemplary embodiment of the present disclosure, and referring to fig. 1, the method includes:

step S110, acquiring a first position attribute of an operation code executed in a virtual machine at present, wherein the first position attribute comprises an identifier 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;

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

In the technical solution provided in the embodiment shown in fig. 1, first, a first location attribute of an obtained currently executed opcode in a virtual machine is matched 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, the breakpoint in the preset breakpoint storage container configuration code debugging can improve the breakpoint setting efficiency; on the other hand, the first position attribute of the currently executed operation code in the virtual machine is matched with the second position attribute of the breakpoint configured in the preset breakpoint storage container to trigger the breakpoint debugging function, so that the influence of the frequent process of 'interruption-condition judgment-continuous execution' of the virtual machine process in the related art on the code debugging performance can be avoided, and the code debugging efficiency is improved.

The following detailed description of the various steps in the example shown in fig. 1:

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

The script code in the present exemplary embodiment may comprise 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 the execution are completed by the corresponding engine driver, the compiling module of the engine driver first compiles the LPC script code into an opcode (operation code), then the virtual machine module of the engine driver circularly reads in one opcode, and executes different functions according to the read opcode, 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 the opcode currently read in 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 identifier of the object script code file to which the operation code belongs may include a name of the object script code file to which the operation code belongs, and the location information of the script code corresponding to the operation code in the object script code file may include a line number of the script code corresponding to the operation code in the object script code file.

For example, if the script code a on the 5 th line of the LPC script code file 1 is compiled into opcode1 (opcode 1), and the "eval _ instruction" function in the virtual machine code interpret.c indicates that the current opcode is opcode1, then the first location attribute of opcode1 can be obtained as: line 5 of the LPC script code file 1 indicates that the script code A corresponding to opcode1 is on line 5 of the LPC script code file 1.

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

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

The second location attribute of the breakpoint includes an identification of a 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 a few lines of which script code file the breakpoint is configured in.

The breakpoint status of an element includes a first status that no breakpoint is stored or that a stored breakpoint has been removed, a second status that a breakpoint has been stored and the stored breakpoint is invalid, and a third status that a breakpoint has been stored and the stored breakpoint is 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 state of an element is a first state, it indicates that no breakpoint data is currently stored in the element or stored breakpoint data is removed, that is, the element may be used to store breakpoint data newly added by a user; when the breakpoint status of an element is the second status or the third status, it indicates that the breakpoint data has already been stored in the element, and cannot be used for storing other breakpoint data newly added by the user currently. When the breakpoint state of the element is the second state, the breakpoint debugging function is not triggered, and when the breakpoint state of the element is the third state, the breakpoint debugging function is triggered.

For example, a global array may be defined for storing breakpoint information added by a user (e.g., a code debugger), i.e., the array may be stored for the preset breakpoints. The size of the global array can be customized according to requirements, for example, a global array including 10 elements is defined, and the size of the array meets the requirement of debugging breakpoint quantity without affecting the performance of code operation. 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 of the first state, the second state, and the third state, and the state flag in the structural body of each element is 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 schematic diagram illustrating a storage structure of a preset breakpoint storage array in an exemplary embodiment of the present disclosure. Referring to fig. 2, 21 represents an element in the preset breakpoint storage array, and 22 represents breakpoint data stored in the element in the preset breakpoint storage array, including a breakpoint status 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 a first state, that is, the first state in which the breakpoint is not set.

Illustratively, before breakpoint debugging is performed on the script language code, breakpoint data required during debugging can be added to the preset breakpoint storage array according to debugging requirements. Fig. 3 is a flowchart illustrating a method for 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 to add the target breakpoint, the elements in the preset breakpoint storage array are traversed according to the ascending order of the index values of the elements.

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

Furthermore, the user can remove the unnecessary breakpoint data from the preset breakpoint storage array according to the requirement. For example, fig. 4 is a flowchart illustrating a method for 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 the operation instruction for removing the target breakpoint, the breakpoint state of the target element corresponding to the target breakpoint is reconfigured to be the first state.

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

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, sequentially moving the breakpoint data stored in the element to be adjusted forward to the previous element corresponding to the element to be adjusted for storage, for the element to be adjusted.

In the preset breakpoint storage array, the index value of the element to be adjusted behind the target element is greater than the index value of the target element. That is to say, the element to be adjusted may include an element whose index value in the preset breakpoint storage array is greater than the 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 or more than the third state after the target element corresponding to the target breakpoint, it is only necessary to reconfigure the breakpoint state of the target element corresponding to the target breakpoint to the first state. The first state at this time may be understood as the current element storing the breakpoint but the stored breakpoint has been removed.

Illustratively, fig. 5 shows a schematic diagram of states of preset breakpoint storage arrays before and after breakpoint removal in an exemplary embodiment of the present disclosure. Referring to fig. 5, the breakpoint stored in element 51 is the target breakpoint that needs to be removed, that is, the target breakpoint that needs 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 statuses of the 4 th element and the 5 th element are the second status or the third status, when the target breakpoint "test.c: 3" is removed, the breakpoint status of the 3 rd element may be reconfigured to the first status, 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 moved forward for storage, the breakpoint status of the element in the breakpoint data remains unchanged, for example, before the breakpoint data stored in the 4 th element is moved forward to be stored in the 3 rd element, the breakpoint status of the element stored in the 4 th element is in the second state, and after the movement, the breakpoint status of the element stored in the 3 rd element is still in the second state. That is, the previously reconfigured first state of the 3 rd element is again replaced 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 can be modified through a preset breakpoint state configuration instruction. The specific implementation mode can be as follows:

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

and responding to the effective state configuration instruction aiming at the target breakpoint, and reconfiguring 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 breakpoint is added to a preset array, a debugger does not need to use the breakpoint for a while, and may configure the state of an element storing the breakpoint in the preset storage array to a second state through a preset breakpoint invalid state configuration instruction, and may reconfigure the state of the element storing the breakpoint in the preset storage array to a third state through the preset breakpoint valid state configuration instruction when the breakpoint needs to be used again.

Furthermore, the configured breakpoint data can be inquired through a preset breakpoint data inquiry instruction. The specific implementation mode can be as follows:

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

In an exemplary embodiment, the first preset format may include displaying the searched breakpoint data at the client according to the identification of the script file to which the breakpoint belongs, the position information of the breakpoint in the script file to which the breakpoint belongs, and the sequence of the breakpoint statuses of the elements. The queried breakpoint data is displayed at the client, for example, according to the format of "test.c: 7, B". Where B can be understood as the status flag of the second status pair described above, which indicates that a breakpoint is set on line 7 of the test.c file, and the status of the current breakpoint is invalid.

For example, a breakpoint data operation function matched with a preset breakpoint array can be written in advance, and functions of adding a breakpoint, removing a breakpoint, invalidating or validating the breakpoint, and viewing 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 the breakpoint is added, the breakpoint data operation function can traverse the preset breakpoint data storage array until the element with the state mark field of A is encountered, and then the breakpoint is added and the breakpoint state mark of the element is modified into C; when the breakpoint is removed, the breakpoint data operation function can modify the breakpoint state flag of the element corresponding to the breakpoint into a and move all the breakpoint data after the breakpoint forward one; when the breakpoint is invalid, 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 may return the breakpoint data stored in the preset breakpoint storage array according to the first preset format.

Further, the breakpoint data operation function may be packaged as a breakpoint addition instruction (break), a breakpoint removal instruction (delete), an invalid state setting instruction (disable), an valid state setting instruction (enable), and a breakpoint query instruction (info). Therefore, a code debugger can conveniently call the breakpoint data operation function according to the corresponding instruction to realize the corresponding function.

After the breakpoint data is preconfigured in the preset breakpoint storage container, the first position attribute obtained in step S110 may be matched with the second position attribute of the breakpoint stored in the preset breakpoint storage container, so as to implement breakpoint debugging of the LPC script language code.

Fig. 6 is a flowchart illustrating a method for 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, the 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 an element may comprise a subscript of the element.

In step S620, when the stored element whose second location attribute is the same as the first location attribute and whose breakpoint status is the third status is traversed, stopping the traversal and determining that the first location attribute and the second location attribute of the breakpoint configured in the preset breakpoint storage container are successfully matched.

In step S630, when the stored breakpoint status is traversed to the element in the first status, stopping the traversal and determining that the first location attribute fails to match the second location attribute of the breakpoint configured in the preset breakpoint container, so that the virtual machine continues to execute the next opcode.

For example, a section of code may be inserted before the opcode is executed in the "eval _ instruction" function of the virtual machine code interpret.c of the LPC, the function of the code is to traverse a preset breakpoint storage array, and once it is determined that the first position attribute of the current opcode is the same as the second position attribute stored in an element whose breakpoint state is the third state, it is determined that the matching is successful, that is, the current opcode is determined to be a breakpoint, and the traversal may be stopped; and once the element with the breakpoint state being the first state is encountered, determining that the matching fails, namely judging that the current opcode is not the breakpoint, stopping traversing, and enabling the virtual machine to continue to execute the next opcode.

In this disclosure, since the adding and removing of the breakpoint are implemented by the breakpoint adding method in the steps S310 to S320 and the breakpoint removing method in the steps S410 to S440, respectively, the breakpoint can be set in front of the array, and the breakpoint state of the element is stored in the breakpoint data, so that 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 can be determined according to the breakpoint state of the element, so that the traversal can be terminated in advance, the judgment speed of the breakpoint is increased, and the efficiency and performance of breakpoint debugging can be further improved.

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

In an exemplary embodiment, the interruption mode may include running to the next interruption point (continue), single step skip (next), single step enter (step), single step complete (finish).

For example, a global interrupt mode variable, such as a G _ break _ flag variable, may be defined, which has 4 values, where a value D represents that the interrupt mode is run to the next interrupt point (continue), a value E represents that the interrupt mode is single step skip (next), a value F represents that the interrupt mode is single step enter (step), and a value G represents that the interrupt mode is single step complete (finish).

Meanwhile, a GDB extended python script can be written, four commands of continue, next, step and finish are respectively packaged in the script, when the four commands are packaged, the value of g _ break _ flag is changed into a value corresponding to each command, then the continue command of the GDB is executed, and the execution right is handed back to the process of the virtual machine after the implementation is interrupted.

For example, when the command whose interruption mode is to be run to the next interruption point is encapsulated, the value of g _ break _ flag may be taken as E, and then the continue command of the GDB is executed. Therefore, when the user inputs the continue command, the user can know that the current interrupt mode is running to the next breakpoint, and after the breakpoint function is executed at the next breakpoint, the user can return the execution right to the process of the virtual machine by executing the continue command of the GDB.

For example, the specific implementation of step S120 may be: and when the interruption mode is to be operated to the next breakpoint, matching the first position attribute with a 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 called to trigger a breakpoint debugging function at the opcode.

For example, when the interrupt mode is any one of single-step skipping, single-step entering and single-step completing, whether to execute the interrupt may be determined only by judging the change of 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 to perform matching between the first position attribute and the second position attribute of the breakpoint configured in the preset breakpoint storage container. When the interruption mode of the breakpoint is single step skipping, single step entering and single step completion, whether interruption is executed or not is determined directly according to the change of the depth of the call stack without traversing a preset breakpoint storage container.

Fig. 7 is a flowchart illustrating a method for debugging code according to an interrupt manner 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 opcode currently executed in the virtual machine is obtained;

in step S720, the current interrupt mode is determined, when the current interrupt mode is running to the next interrupt point, 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 enter, step S750 is executed, and when the current interrupt mode is single step complete, step S760 is executed.

In step S730, it is determined whether the first location attribute matches a second location attribute of a breakpoint configured in a preset breakpoint storage container, and if the first location attribute matches the second location attribute, step S770 is executed, and if the first location attribute does not match the second location attribute, 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 so, step S770 is executed, and if not, 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 so, step S770 is executed, and if not, step S780 is executed.

In step S760, it is determined whether the current call stack depth is smaller than the previous call stack depth, if so, step S770 is executed, and if not, step S780 is executed.

In step S770, a preset breakpoint jump function is called to trigger a breakpoint debugging function.

In step S780, the next opcode continues to be executed.

Through the above steps S710 to S780, the interrupt debugging function can be implemented in different manners. 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, and the address at the top of the current call stack is stored, and the greater the call stack depth, the greater the call stack pointer csp, so that when the interrupt mode is any one of single step skip, single step enter, and single step complete, it can also determine whether to execute the interrupt by judging the change of the call stack pointer csp of the virtual machine, and replace the technical term "call stack depth" in the above steps S710 to S780 with "call stack pointer csp".

For example, the above-mentioned method for debugging scripting language code may further include: responding to a preset code debugging instruction, starting a code debugging process, and adding a breakpoint debugging function at a preset breakpoint jump function so as to trigger the breakpoint debugging function when the preset breakpoint jump function is called.

The added breakpoint debugging function can include a breakpoint debugging function carried by the GDB. After the breakpoint debugging function is added to 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, and the code in the function is arbitrary, for example, the function may call debug _ message (msg) to print out information of interest, and use the function as a preset breakpoint jump function. Meanwhile, a GDB extended python script can be written: and after the python script is started, the user input is received in an infinite loop mode, and the user input is used as an instruction for analysis. A code debugging instruction, for example, an attach instruction, may be encapsulated in the python script, where the instruction may serve as the preset code debugging instruction, and functions as: starting a code debugging process, automatically adding a breakpoint at a preset breakpoint jump function 'debug _ trigger', wherein the preset breakpoint jump function can be understood as automatically adding a breakpoint debugging function carried by the GDB at the preset breakpoint jump function, and once the process of the virtual machine calls the debug _ trigger function, the breakpoint can be triggered, namely the breakpoint debugging function carried by the GDB is triggered to realize breakpoint debugging of the script language code.

Illustratively, for convenience of code debugging, script code near a breakpoint may also be presented to a user when an interruption occurs. FIG. 8 shows a flowchart of a method for 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 debugging function, acquiring a first position attribute of the opcode;

in step S820, based on the first location attribute, reading a script code to be printed in 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 a second preset format.

For example, in a written GDB extended Python script, a breakpoint processing function in the GDB is registered through a GDB. For example, the script codes of two lines before and after the line number of the script code corresponding to the current opcode are read and formatted for printout.

According to the 7 th behavior example of the currently triggered breakpoint in the demo.c file, the following printing script codes can be output according to a second preset format:

“demo.c:7

5:{

6：int a＝101；

7：int b＝202；

8：int c＝a+b；

(LPC_GDB)”

wherein, the code '5, 6, 7, 8' is the line number where the script code is located, and demo.c:7 is the second position attribute of the set breakpoint.

Illustratively, after the breakpoint debugging function is triggered at the opcode, the method for debugging the scripting language code further includes:

in response to a view instruction for a target global variable value during a current interrupt, calling a first preset function to query the target global variable value and generating a first serialization string of the target global variable value to display the first serialization string at a client;

and in response to the modification instruction aiming at the target global variable value during the current interrupt, calling a second preset function to perform deserialization on 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 for printing variable values and importing variable values may be added in the virtual machine of the script code to implement the function 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). The first preset function may return a serialized string of the value of the global variable input 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 the 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 value of the queried global variable.

Further, a second preset function may be defined, and a name of the second preset function may be restore _ global _ value (char name, char value). The second preset function may assign a value obtained by deserializing the value character string input by the user to the global variable corresponding to the name. Specifically, the second preset function may call a restore _ svalue function in the object.c file in the virtual machine code of the LPC to deserialize the character string input by the user.

The serialization can be understood as converting values of different types of variables stored in a virtual machine into character string types, and because the LPC variable values stored in the virtual machine have various types including integer types, character strings, arrays, dictionaries and the like, when the values of the variables of the types are displayed to a user, the values need to be serialized and converted into the character strings, and then the character strings are printed on a display interface of a client; similarly, the values of the user-entered variables are usually in the form of strings, and therefore, when the values of the different types of variables are modified using the values of the user-entered string types, it is necessary to deserialize the strings into the values of the corresponding variable types.

Illustratively, after the opcode triggers the breakpoint debugging function, the method for debugging the scripting language code further includes:

responding to a viewing instruction aiming at the target local variable value during the current interruption, calling a third preset function to determine the index value of the target local variable based on a local variable index table generated in advance, 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 responding to a modification instruction aiming at the target local variable value in the current interrupt period, calling a fourth preset function to perform deserialization on the target local variable value in the modification instruction, determining an index value corresponding to the target local variable based on a local variable index table generated in advance, 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 can be viewed and modified by way of an index. The start address of the current local variable is stored in the variable fp of the virtual machine code interpret.c, and the local variable value to be queried can be indexed through (fp + index), wherein the index is an 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 a serialized string of the value of the local variable. Likewise, the third preset function may call the save _ variable _2 function in object.c file of the virtual machine code of the LPC to serialize the value of the queried local variable.

For the 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 value), and the fourth preset function may assign the value string deserialized value to the local variable corresponding to the index. Likewise, the fourth preset function may call a restore _ svalue function in the 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 in an exemplary embodiment of the disclosure. Referring to fig. 9, the method may include steps S910 to S920.

In step S910, when compiling the script code file, for each analyzed local variable definition, acquiring an identifier of the script code file to which the local variable belongs, an identifier of a function to which the local variable belongs, location information of the local variable, and an order in which the local variable is defined in the local variables included in the function.

The position information of the local variable comprises position information of the local variable definition in the script code file, for example, a line number of the local variable definition in the script code file. The order in which the local variables are defined among the local variables contained in the function may include the number of local variables defined in the function to which the current local variable belongs.

Illustratively, in the process of debugging the script code file, the 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 opcode. When compiling the script code file, when the local variable definition is analyzed, the name of the script code file where the currently defined local variable is located, the name of the function, the line number where the currently defined local variable definition is located in the script code file, and the number of the currently defined local variable in the function to which the currently defined local variable belongs can be obtained.

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

For example, when a local variable is defined in a certain 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 defined local variable in the function, position information at a definition 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 with the same name and different scopes in a certain function, and the local variables with the same name need to store the position information and the defined sequence of their corresponding definitions respectively.

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

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

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

For example, during the current interruption, the local variable index table determined by the identification of the script code file to which the current breakpoint causing the current interruption 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, a local variable to be queried is determined, where the local variable to be queried has the same identifier as the target local variable in the view instruction or the modification instruction, and the location information of the local variable is less than or equal to the location information of the current breakpoint in the target script code file.

For example, during the interruption, the local variable to be modified or viewed is the local variable at or before the breakpoint, and therefore, the local variable which has the same identification as the local variable in the corresponding instruction and whose position information is less than or equal to the position information of the current breakpoint in the script code file needs to be determined in the local variable index table to be queried.

Next, in step S1030, the local variable to be queried whose difference between the position information and the position information of the current breakpoint in the target code file is the minimum is determined as the target local variable.

For example, as described above, in the same function, there may be local variables with the same name and different scopes due to being defined at different positions of the script code file, and therefore, 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 sequence corresponding to the target local variable, an index value corresponding to the target local variable in the view instruction or the modify instruction is determined.

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

For example, after determining an index value corresponding to a local variable, for example, idex, a start address of a current target local variable is stored in a variable fp in the virtual machine code interpret.c, and according to (fp + index), the value of the current target local variable may be indexed to perform a modification or query operation thereon.

For example, in the syntax parsing stage, when parsing to the local variable definition, the LPC file name, the function name, the line number in the LPC file, and the sequence in which the currently defined local variable is defined in the corresponding function (i.e. a definition sequence number, which may indicate that the local variable is the second local variable in the function in which the local variable is located) may be obtained, at this time, a local variable index table file may be saved in the form of "file name + function name", and then the local variable name, the line number in the LPC file, and the sequence defined in the corresponding function may be added to the saved local variable index table file.

During dynamic debugging, after a breakpoint of an LPC script is triggered, an LPC file name, a function name and a line number of the current breakpoint in an LPC file can be obtained in a virtual machine, at this time, when a value of a certain local variable needs to be modified or checked, a local variable having the same name as the local variable name needing to be modified or checked and a corresponding line number smaller than or equal to the line number of the current breakpoint can be found in a local variable index table corresponding to the LPC file name and the function name of the current breakpoint, and the difference between the corresponding line number and the line number of the current breakpoint is the smallest, that is, the local variable to be queried or modified, a defined sequence corresponding to the local variable is taken out and used as the index value index of the local variable, and then the current value of the target local variable can be indexed according to (fp + index).

In an exemplary embodiment, the GDB extended python script may be written to encapsulate instructions to modify or view global or local variables for user convenience. Specifically, the LPC _ file module may be written, and the function of the LPC _ file module is to parse an LPC script file, parse a definition sequence of local variables in each function, and generate a local variable index table in advance, so that an index value of a local variable to be queried or modified at present may be determined through the local variable index table.

Meanwhile, four commands of print, set, print _ local, and set _ local may be encapsulated, and the print command and the set command directly transfer the variable name input by the user into the first preset function (e.g., dump _ global _ value function) and the second preset function (e.g., restore _ global _ value function), respectively, to view and modify the global variable. The print _ local command and the set _ local command respectively convert a variable name input by a user into corresponding index values through the lpc _ file module, and then respectively transfer 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) to view and modify local variables.

Further, after the breakpoint debugging function is triggered at the opcode, the method further includes: and in response to a viewing instruction aiming at the call stack at the current breakpoint during the current interrupt, calling a fifth preset function to traverse the stack frame of the virtual machine so as to acquire the 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.

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

For example, 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 disconnection point of the LPC according to the third preset format.

For example, a fifth preset function "dump _ backup ()" may be defined, which functions to form a string from the LPC call stack at the current breakpoint and return the string. Specifically, a starting address of a call stack is stored in a variable control _ stack in the virtual machine code interpret.c of the LPC, csp is an address of the current stack top, and each stack frame of the call stack includes location information of a next function to be called and an index of the next function in a next LPC file function table. For example, a certain 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}”

in the 12 lines of codes, the first number of each line of codes is the line number of the code, and the line number does not belong to the content of the code. If a breakpoint is triggered on line 11 of the above 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 indicate: the test () function is called at line 11 of demo.c, and then the test2() function is called again at line 7 of demo.c in the test () function.

In an exemplary embodiment, the instruction for querying the call stack at the breakpoint may be packaged, for example, a fifth preset function is packaged as a "backspace" instruction, and when the "backspace" instruction is input by a user, the fifth preset function may be called to implement 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 includes:

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

For example, fig. 11 is a flowchart illustrating a method for calling 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 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 the at least one calling parameter input by the user may be moved to the 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 identifier of the script file in the top of the runtime stack, the identifier of the target script function, and the value of the call parameter, and the return value of the target script function is stored to the 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 the script code file to be called, an identifier of the function, and a value of the parameter, then a corresponding function in the corresponding script code file is called according to the identifier of the script code file, the identifier of the function, and the value of the parameter, and a return value of the function is stored at the 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 stack 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 before the target script function is executed. Therefore, the execution calling of the target script function during the interruption can be realized, and the subsequent debugging process is not influenced.

For example, a sixth preset function may be predefined, the name of the sixth preset function may be "call _ distributor _ function", and the form of the corresponding sixth preset function may be "call _ distributor _ function (char _ filename, char _ funcname, int numag, …)". 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 of parameters to be transmitted, respectively, and the last "…" is a variable length parameter, where the variable length parameter indicates that numag character strings can be transmitted, and each character string can be deserialized into one 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 take the return value of the target script function as the return value of the sixth preset function. The sixth preset function may be implemented as follows: the method comprises the steps of calling a built-in function ' push _ svalue ' of the virtual machine to move an incoming ' filename, funcname and a plurality of parameter values (namely the parameter values of numag character strings after being deserialized) to the top of a runtime stack, then calling a built-in function ' f _ call _ other ' in the virtual machine, and finally calling a built-in function ' pop _ stack ' in the virtual machine to restore the top of the runtime stack to a state before a target script function is executed.

The function of the "f _ call _ other" function is to regard 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 top of the stack, and take it at the place to be called.

Fig. 12 is a flowchart illustrating another script code debugging method in an exemplary embodiment of the 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. For the description of the first location attribute in step S1210, reference may be made 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 position attribute is matched with the second position attribute of the breakpoint in the preset breakpoint storage array.

In step S1230, it is determined whether a breakpoint is set at the current opcode, if so, go to step S1240, otherwise, go to step S1250.

For example, when the first location attribute is the same as the second location attribute of the breakpoint in the preset breakpoint storage array, it is determined that the breakpoint is set at the current opcode, otherwise, no breakpoint is set at the current opcode.

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

For example, whether the breakpoint set at the current opcode is valid may be determined according to the breakpoint status of the elements in the preset breakpoint storage array. The second state is invalid, and the third state is valid.

In step S1250, the next opcode continues to be executed.

In step S1260, a preset breakpoint debug function is called to implement interruption at the current opcode.

Through the embodiment of the disclosure, through the transformation of the virtual machine program, the triggering of the judgment breakpoint can be directly carried out in the virtual machine from the conditional breakpoint mode of the GDB, the consumption of frequent interruption is avoided, the running performance in the debugging process is greatly improved, and the efficiency of the dynamic debugging of the LPC script language codes is improved.

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

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

Through related preset functions and corresponding packaging instructions, the functions of checking and modifying variable values accessible at the breakpoint, printing the function of a call stack at the current breakpoint of the LPC and executing any specified script function during interruption can be realized, and a user can further conveniently and efficiently debug LPC script codes by using a GDB tool.

Those skilled in the art will appreciate that all or part of the steps implementing the above embodiments are implemented as computer programs executed by a CPU. The computer program, when executed by the CPU, performs the functions defined by the 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 or optical disk, or the like.

Furthermore, it should be noted that the above-mentioned figures are only schematic illustrations of the processes involved in the method according to exemplary embodiments of the invention, and are not intended to be limiting. It will be readily understood that the processes shown in the above figures are not intended to indicate or limit the chronological order of the processes. In addition, it is also readily understood that these processes may be performed synchronously or asynchronously, e.g., in multiple modules.

Fig. 13 is a schematic structural diagram of a scripting language code debugging apparatus in an exemplary embodiment of the present disclosure. Referring to fig. 13, the scripting language code debugging apparatus 1300 may include a first location attribute obtaining 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;

a breakpoint debugging function triggering module 1330 configured to, when the matching is successful, call a preset breakpoint jump function to trigger the breakpoint debugging function at the opcode.

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

In an exemplary implementation manner of the present disclosure, based on the foregoing embodiment, the above-mentioned script language code debugging apparatus 1300 may further include a breakpoint adding module and a breakpoint removing module, where:

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

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

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

the breakpoint invalidation module is configured to respond to an invalid state configuration instruction aiming at a target breakpoint, and reconfigure the breakpoint state of a target element corresponding to the target breakpoint into a second state in the preset breakpoint storage array;

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

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

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

when the stored second position attribute is traversed to be the same as the first position attribute and the breakpoint state is an element of a third state, 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;

In an exemplary embodiment of the present disclosure, based on the foregoing embodiment, the scripting language code debugging apparatus 1300 further includes an interruption manner determination module configured to:

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

In an exemplary embodiment of the present disclosure, based on the foregoing embodiment, the above-mentioned script language code debugging apparatus 1300 further includes a breakpoint code printing module configured to:

In an exemplary embodiment of the present disclosure, based on the foregoing embodiment, the above-mentioned script language code debugging apparatus 1300 further includes a global variable access module, which is specifically configured to:

In an exemplary embodiment of the present disclosure, based on the foregoing embodiment, the above-mentioned script language code debugging apparatus 1300 further includes a local variable access module, which is specifically configured to:

In an exemplary embodiment 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 an index value corresponding to a target local variable based on a pre-generated local variable index table includes:

In an exemplary embodiment 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 embodiment of the present disclosure, based on the foregoing embodiment, the scripting language code debugging apparatus 1300 further comprises an object scripting function execution module configured to:

The specific details of each unit in the above-mentioned script language code debugging apparatus have been described in detail in the corresponding script language code debugging method, and therefore are not described herein again.

It should be noted that although in the above detailed description several modules or units of the 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, according to embodiments of the present disclosure. Conversely, the features and functions of one module or unit described above may be further divided into embodiments by a plurality of modules or units.

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

Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, 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 (which may be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which may be a personal computer, a server, a mobile terminal, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.

In an exemplary embodiment of the present disclosure, there is also provided a computer storage medium capable of implementing the above method. On which a program product capable of implementing the above-described method of the present specification is stored. In some possible embodiments, various aspects of the disclosure may also be implemented in the form of a program product comprising program code for causing a terminal device to perform the steps according to various exemplary embodiments of the disclosure described in the "exemplary methods" section above 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 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. A readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

A computer readable signal medium may include a propagated data signal with readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. 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 for 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 and partly on a remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, 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., through 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.

As will be appreciated by one skilled in the art, aspects of the present disclosure may be embodied as a system, method or program product. Accordingly, various aspects of the present disclosure may be embodied in the form of: an entirely hardware embodiment, an entirely software embodiment (including firmware, microcode, etc.) or an embodiment combining hardware and software aspects that may all generally be referred to herein as a "circuit," module "or" system.

An electronic device 1500 according to such an embodiment of the disclosure is described below with reference to fig. 15. The electronic device 1500 shown in fig. 15 is only an example and should not bring any limitations to the function and scope of use of the embodiments of the present disclosure.

As shown in fig. 15, electronic device 1500 is in the form of a general purpose computing device. 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 different system components (including the storage unit 1520 and the processing unit 1510), and a display unit 1540.

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

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

The storage unit 1520 may include readable media in the form of volatile storage units, such as a random access memory unit (RAM)15201 and/or a cache memory unit 15202, and may further include a read only memory unit (ROM) 15203.

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 of which, or some combination thereof, may comprise an implementation of a network environment.

Bus 1530 may be any 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 can also communicate with one or more external devices 1600 (e.g., keyboard, pointing device, bluetooth device, etc.), with one or more devices that enable a user to interact with the electronic device 1500, and/or with any devices (e.g., router, modem, etc.) that enable the electronic device 1500 to communicate with one or more other computing devices. Such communication may occur via input/output (I/O) interface 1550. Also, the electronic device 1500 may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the internet) via the network adapter 1560. As shown, the network adapter 1560 communicates with the 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 conjunction with the electronic device 1500, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.

Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, 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 (which may be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which may be a personal computer, a server, a terminal device, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.

Furthermore, the above-described figures are merely schematic illustrations of processes included in methods according to exemplary embodiments of the present disclosure, and are not intended to be limiting. It will be readily understood that the processes shown in the above figures are not intended to indicate or limit the chronological order of the processes. In addition, it is also readily understood that these processes may be performed synchronously or asynchronously, e.g., in multiple 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 variations, 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 method for debugging scripting language codes is characterized by comprising the following steps:

2. The scripting 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 in each element in the preset breakpoint storage array comprises a second position attribute of the breakpoint and a breakpoint status of the element;

3. The scripting language code debugging method of claim 2, further comprising:

4. The scripting language code debugging method of claim 3, further comprising:

5. The method for debugging scripting language code according to claim 3, wherein said matching said 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 of claim 5, further comprising:

7. The method for debugging scripting language code according to claim 1, wherein said matching said first location attribute with a second location attribute of a breakpoint configured in a preset breakpoint storage container comprises:

8. The scripting language code debugging method of claim 7, further comprising:

9. The scripting language code debugging method of claim 1, further comprising:

10. The scripting language code debugging method of any one of claims 1 to 9, further comprising:

11. The scripting language code debugging method of claim 1, wherein after a breakpoint debugging function is triggered at the opcode, the method further comprises:

12. The scripting language code debugging method of claim 1, wherein after a breakpoint debugging function is triggered at the opcode, the method further comprises:

13. The debugging method according to claim 12, wherein said 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.

14. The method for debugging scripting language code according to claim 13, wherein said determining an index value corresponding to a target local variable based on a pre-generated local variable index table comprises:

15. The scripting language code debugging method of claim 1, wherein after a breakpoint debugging function is triggered at the opcode, the method further comprises:

16. The scripting language code debugging method of claim 1, wherein after a breakpoint debugging function is triggered at the opcode, the method further comprises:

17. A scripting language code debugging apparatus, comprising:

18. A computer-readable storage medium, on which a computer program is stored, which program, when being executed by a processor, carries out the method according to any one of claims 1 to 16.

19. 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 carry out the method of any one of claims 1 to 16.