Method, medium and equipment for checking use condition of file input and output

Abstract

The invention discloses a method, medium and equipment for viewing the use condition of file input and output, and the method comprises the steps: executing breakpoint registration based on a file IO operation type for at least one file IO operation type by utilizing an extended GDB plug-in; in the program execution process, under the condition that a pre-registered breakpoint based on a file IO operation type is triggered by a file IO operation in the program, a method for setting the breakpoint in the GDB is called; determining the type of the file IO operation of the current trigger breakpoint according to the breakpoint setting method, and obtaining the use information of the corresponding file IO according to the type of the file IO operation of the current trigger breakpoint; and outputting the obtained use information of the file IO to a target position. According to the method, the problems caused by the file IO operation in the program can be quickly and accurately found, and the functions of the GDB debugger are enriched, so that the program stability is ensured while the program development and maintenance efficiency is improved.

Description

Technical Field

[0001] This disclosure relates to the field of computers, and more particularly to a method for viewing the usage of file input and output, a computer-readable storage medium, and an electronic device. Background Technology

[0002] Currently, debugging tools are typically used to debug programs. For example, when debugging programs based on the Linux platform, tools such as GDB (GNU's Not Unix) Debugger are commonly used.

[0003] Since debugging tools such as GDB typically do not support viewing file I / O (Input / Output) usage in a program, it is often impossible to troubleshoot issues such as file write / write exceptions, viewing the contents of the buffer in extreme scenarios, and checking for files that have not been properly closed using existing debugging tools like GDB. This makes program debugging difficult.

[0004] As described above, how to enable users to know the file I / O usage involved in the program, so as to quickly and accurately discover program abnormalities caused by file I / O operations, improve program debugging efficiency, and thus improve program development and maintenance efficiency while ensuring program stability and robustness, is a technical issue worthy of attention. Summary of the Invention

[0005] To address the aforementioned technical problems, this disclosure is proposed. Embodiments of this disclosure provide a method, storage medium, and electronic device for viewing file input / output usage.

[0006] According to a first aspect of the present disclosure, a method for viewing file input / output usage is provided, the method comprising the following steps: registering breakpoints based on file I / O operation types for at least one file I / O input / output operation type using an extended GNU debugger plugin; during program execution, if the pre-registered breakpoints based on file I / O operation types are triggered by file I / O operations in the program, invoking a breakpoint setting method in the GNU debugger; wherein the breakpoint setting method in the GNU debugger is the method executed by the GNU debugger when the breakpoint is triggered; the breakpoint setting method determines the type of file I / O operation that currently triggers the breakpoint, and obtains corresponding file I / O usage information based on the type of file I / O operation that currently triggers the breakpoint; and outputting the obtained file I / O usage information to a target location.

[0007] According to a second aspect of the present disclosure, a computer-readable storage medium is provided, the storage medium storing a computer program for implementing the above-described method.

[0008] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a processor; a memory for storing executable instructions of the processor; the processor being configured to read the executable instructions from the memory and execute the instructions to implement the method described above.

[0009] Based on the above embodiments of this disclosure, a method, storage medium, and electronic device for viewing file input / output usage are provided. By registering breakpoints based on file I / O operation types, the corresponding type of file I / O operation in the program can trigger the registered breakpoints when executed, thereby enabling the execution of the breakpoint-setting method in GDB. This disclosure sets custom processing logic for file I / O operations within the breakpoint-setting method. When the registered breakpoint is triggered by the corresponding type of file I / O operation in the program, the custom processing logic is executed, making it possible to obtain file I / O usage information. By outputting file I / O usage information to a target location, this disclosure not only facilitates troubleshooting file write / write anomalies (such as insufficient permissions or full cache space), but also facilitates viewing the contents of the buffer and checking for improperly closed files in some application scenarios. Therefore, the technical solution provided by this disclosure is beneficial for quickly and accurately identifying program anomalies caused by file I / O operations, allowing users to intuitively understand the file I / O operation usage in the program. This enriches the functionality of the existing GDB debugger, improves program debugging efficiency, and ultimately enhances program development and maintenance efficiency while ensuring program stability and robustness.

[0010] The technical solutions of this disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0011] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0012] Figure 1 This is a flowchart of an embodiment of the method for viewing file input and output disclosed herein;

[0013] Figure 2This is a schematic diagram of another embodiment of the method for viewing file input and output according to the present disclosure;

[0014] Figure 3 This is a schematic diagram of an embodiment of the apparatus for viewing file input and output usage disclosed herein;

[0015] Figure 4 This is a structural diagram of an electronic device provided in an exemplary embodiment of this disclosure. Detailed Implementation

[0016] Example embodiments according to this disclosure will now be described in detail with reference to the accompanying drawings. It is obvious that the described embodiments are merely some embodiments of this disclosure, and not all embodiments of this disclosure, and it should be understood that this disclosure is not limited to the example embodiments described herein.

[0017] It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of this disclosure.

[0018] Those skilled in the art will understand that the terms "first," "second," etc., in the embodiments of this disclosure are only used to distinguish different steps, devices, or modules, and do not represent any specific technical meaning, nor do they indicate a necessary logical order between them.

[0019] It should also be understood that in the embodiments disclosed herein, "a plurality of" may refer to two or more, and "at least one" may refer to one, two or more.

[0020] It should also be understood that any component, data or structure mentioned in the embodiments of this disclosure can generally be understood as one or more unless expressly defined or given to the contrary in the context.

[0021] Furthermore, the term "and / or" in this disclosure is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this disclosure generally indicates that the preceding and following related objects have an "or" relationship.

[0022] It should also be understood that the description of the various embodiments in this disclosure emphasizes the differences between the various embodiments, and the similarities or similarities can be referred to each other. For the sake of brevity, they will not be described in detail.

[0023] At the same time, it should be understood that, for ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn according to actual scale.

[0024] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit this disclosure or its application or use.

[0025] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0026] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0027] The embodiments of this disclosure can be applied to electronic devices such as terminal devices, computer systems, and servers, and can operate with a wide range of other general-purpose or special-purpose computing system environments or configurations. Examples of well-known terminal devices, computing systems, environments, and / or configurations suitable for use with electronic devices such as terminal devices, computer systems, or servers include, but are not limited to: personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems, etc.

[0028] Electronic devices such as terminal devices, computer systems, and servers can be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., which perform specific tasks or implement specific abstract data types. Computer systems / servers can be implemented in a distributed cloud computing environment. In a distributed cloud computing environment, tasks can be executed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules can reside on local or remote computing system storage media, including storage devices.

[0029] Exemplary methods

[0030] The method disclosed herein for viewing file input / output usage is mainly applied in program debugging scenarios. This method can intuitively show users the usage of file I / O operations during program execution, thereby enabling users to clearly know whether there are any problems such as program exceptions caused by file I / O operations.

[0031] Figure 1 This is a flowchart illustrating one embodiment of the method for viewing file input and output according to this disclosure. Figure 1The method shown mainly includes the following steps: S100, S101, S102, and S103. The following section details... Figure 1 Each step in the process will be explained separately.

[0032] S100. Utilize the extended GDB plugin to perform breakpoint registration based on at least one file I / O operation type.

[0033] The extended GDB plugins in this disclosure refer to tools or scripts used to extend the functionality of GDB; that is, the extended GDB plugins in this disclosure enhance the program debugging capabilities of GDB itself. The extended GDB plugins of this disclosure can be considered as loadable GDB modules, which can enable GDB to have new functionalities without modifying GDB itself. In an application scenario, the extended GDB plugins of this disclosure can be loaded using commands such as the `source` command, thereby enabling the extended GDB plugins to be executed.

[0034] In this disclosure, file I / O operation types refer to the classification of file I / O operations according to their different functions. A file I / O operation with a single function is considered an operation type. For example, the file I / O operation types in this disclosure can be specifically classified as open file operation type, read file operation type, write file operation type, or close file operation type, etc.

[0035] In this disclosure, breakpoint registration refers to setting special flags for a program. These special flags can be used to pause program execution during debugging, so as to assist program developers / testers in checking and analyzing program code.

[0036] In one example, the number of breakpoints that the extended GDB plugin in this disclosure needs to register is typically related to the number of file I / O operation types. For instance, if breakpoints need to be registered for open file operation types, read file operation types, write file operation types, and close file operation types, the extended GDB plugin needs to register four breakpoints. In one application scenario, the extended GDB plugin in this disclosure can complete breakpoint registration based on file I / O operation types by performing four breakpoint registration operations. Specifically, it uses the extended GDB plugin to perform breakpoint registration for open file operation types, read file operation types, write file operation types, and close file operation types, thereby registering breakpoints for each of these types separately.

[0037] In one example, this disclosure allows setting a custom breakpoint class for file I / O operation types by inheriting the gdb.Breakpoint class, and registering each breakpoint instance / object in the custom breakpoint class by calling the parent class's initialization method in the init method. An example of this disclosure performing breakpoint registration based on file I / O operation types can be represented in the following pseudocode form:

[0038]

[0039]

[0040] By utilizing extended GDB plugins to register breakpoints for open file operation types, read file operation types, write file operation types, and close file operation types, all file I / O operations in the program can be traced. This allows for obtaining file I / O usage information for each file I / O operation in the program, which is beneficial for thoroughly investigating abnormal issues caused by file I / O operations in the program. This helps to avoid the impact of incomplete investigation on the stability and robustness of the program.

[0041] S101. During program execution, if a pre-registered breakpoint based on a file I / O operation type is triggered by a file I / O operation in the program, call the method in GDB that sets the breakpoint.

[0042] The methods for setting breakpoints in GDB disclosed herein refer to the methods that GDB would normally execute when a breakpoint is triggered. These methods can also be considered functions, specifically breakpoint-setting functions in GDB. For example, breakpoint-setting methods in GDB could be the `stop` method, etc.

[0043] This disclosure rewrites the existing methods for setting breakpoints in GDB so that when a breakpoint based on a file I / O operation type pre-registered in this disclosure is triggered by a file I / O operation in the program, the processing logic set by this disclosure for file I / O operations can be executed. In other words, this disclosure adds custom processing logic to the existing methods for setting breakpoints in GDB.

[0044] In one example, the custom processing logic may include: determining the type of file I / O operation and collecting corresponding file I / O usage information for the determined file I / O operation type. This disclosure can either directly output the file I / O usage information to the target location when the custom processing logic collects it, or it can first store the collected file I / O usage information (e.g., in a one-key-value dictionary) and then output the currently stored file I / O usage information to the target location when needed by the user.

[0045] S102. The method for setting breakpoints determines the type of file I / O operation that currently triggers the breakpoint, and obtains the corresponding file I / O usage information based on the type of file I / O operation that currently triggers the breakpoint.

[0046] In one example, the file I / O usage information in this disclosure refers to the content involved in file I / O operations. For example, file I / O usage information may include one or more of the following: file identifier, file name, buffer start position, and buffer size. The file identifier can be an identifier assigned by the system to a file, and it uniquely identifies a file. The file name may include the file's storage path; however, this disclosure does not exclude cases where the file name does not include the file's storage path. The buffer start position may indicate the starting position of the opened file in the buffer in some application scenarios, and in other application scenarios, it may indicate the starting position of the buffer for read / write operations on the opened file. The buffer size indicates the space occupied by the opened file in the buffer. By obtaining the file identifier, it is possible to effectively distinguish all file I / O usage information obtained from all file I / O operations performed on the same file. By obtaining the file name, it is beneficial for program developers / debuggers to clearly know the file targeted by each file I / O operation in the program. When the starting position of the buffer indicates the starting position of the read / write operation buffer, obtaining the starting position of the buffer is helpful for program developers / debuggers to view the specific content of the read / write operation. When the starting position of the buffer indicates the starting position of the file in the buffer, combining the size of the buffer and the starting position of the buffer is helpful for program developers / debuggers to view the specific content of the file opened by the program.

[0047] In one example, when the breakpoint is triggered by a method in the program, the name of the method triggering the breakpoint indicates the type of file I / O operation. Therefore, the breakpoint setting method in GDB of this disclosure can determine the type of file I / O operation triggered by the method name. Furthermore, since the input parameters of the breakpoint triggering method reflect file I / O usage, the breakpoint setting method in GDB can obtain the corresponding file I / O usage information from the input parameters of the method triggering the breakpoint. This disclosure, by utilizing the breakpoint triggering method name and input parameters, not only facilitates the convenient and accurate determination of the type of file I / O operation triggered by the breakpoint but also facilitates the convenient acquisition of the corresponding file I / O usage information.

[0048] In one example, when a pre-registered breakpoint is triggered by a method in the program, the method set for the breakpoint in GDB is invoked. This method first retrieves the name of the method that triggered the breakpoint, for example, `function_name`. If `function_name` is "open", it determines that the method triggering the breakpoint is an open file method, and the type of file I / O operation is an open file operation. If `function_name` is "read", it determines that the method triggering the breakpoint is a read file method, and the type of file I / O operation is a read file operation. If `function_name` is "write", it determines that the method triggering the breakpoint is a write file method, and the type of file I / O operation is a write file operation. If `function_name` is "close", it determines that the method triggering the breakpoint is a close file method, and the type of file I / O operation is a close file operation.

[0049] In one example, the file I / O usage information disclosed herein includes, in addition to: file identifier, file name, buffer start position, and buffer size, a read flag and a write flag. The read flag indicates that the file I / O usage information was obtained for a read file operation. The write flag indicates that the file I / O usage information was obtained for a write file operation. By setting read and write flags in the file I / O usage information, the file operation type corresponding to each piece of file I / O usage information can be clearly indicated. This allows for effective differentiation of all file I / O usage information obtained for the same file, which is beneficial for program developers / debuggers to troubleshoot read / write anomalies in file I / O operations within the program.

[0050] In one example, each type of file I / O operation corresponds to specific file I / O usage information. The usage information for different types of file I / O operations can be the same (e.g., the usage information for write and read file operations is the same) or different (e.g., the usage information for open and read file operations is different). Furthermore, the usage information for each type of file I / O operation can be set according to the user's actual needs. In one application scenario, the usage information for open file operations might include: file identifier and file name; for write file operations, it might include: file identifier, buffer start position, buffer size, and a write flag; for read file operations, it might include: file identifier, buffer start position, buffer size, and a read flag; and for close file operations, it might include: file identifier.

[0051] In one example, when the breakpoint setting method in GDB determines that the file I / O operation triggering the breakpoint is an open file operation, it can obtain the filename (e.g., "file") of the currently opened file from the input parameters of the open file method (e.g., the function open()). Then, the breakpoint setting method in GDB can allow the open file method to continue execution using a release command (e.g., the finish command). After successful execution, the open file method returns the file identifier assigned by the system to the currently opened file. This returned file identifier can be stored in the rax register. The breakpoint setting method in GDB can obtain the file identifier corresponding to the filename based on the return information of the open file method, for example, by reading data from the rax register.

[0052] In one example, the breakpoint setting method in GDB, when determining that the type of file I / O operation that triggered the breakpoint is a file read operation, can not only obtain the file identifier, the starting position of the buffer, and the size of the buffer from the input parameters of the file read method (such as the function read()) that triggered the breakpoint, but also set the read flag for the currently obtained file identifier, the starting position of the buffer, and the size of the buffer.

[0053] In one example, the breakpoint setting method in GDB, when determining that the type of file I / O operation that triggered the breakpoint is a write file operation, can not only obtain the file identifier, the starting position of the buffer, and the size of the buffer from the input parameters of the write file method (such as the function write()) that triggered the breakpoint, but also set the write flag for the currently obtained file identifier, the starting position of the buffer, and the size of the buffer.

[0054] In one example, the breakpoint setting method in GDB can obtain the file identifier from the input parameters of the file close method (such as the function close()) of the currently triggering breakpoint when it determines that the type of file I / O operation that triggered the breakpoint is a file close operation.

[0055] As described in the examples above, this disclosure can conveniently and accurately obtain the file I / O usage information corresponding to each of the open file operation type, read file operation type, write file operation type, and close file operation type. By setting the file identifier, the starting position of the buffer, and the size of the buffer obtained from the input parameters of the corresponding method to a read flag or a write flag, the corresponding file I / O usage information is formed, which can effectively distinguish the file I / O usage information corresponding to the read file operation type and the write file operation type. Since all the obtained file I / O usage information includes the file identifier, the file I / O usage information for different files can be effectively distinguished, and it is also beneficial to comprehensively and accurately reflect the file I / O usage of all files involved in the program.

[0056] In one example, the breakpoint setting method in GDB can store the file I / O usage information obtained each time it is acquired. The set of file I / O usage information formed by multiple storages can be output in subsequent processes. For example, this disclosure can output all or part of the currently stored file I / O usage information to the target location by inputting the corresponding output command.

[0057] In one example, the breakpoint setting method in GDB can store file I / O usage information for each acquisition in the form of key-value pairs. For instance, the breakpoint setting method in GDB can use the file identifier as the key and store the file name, the starting position of the buffer, the size of the buffer, the read flag, and the write flag as the values ​​in a key-value pair set, which can be a key-value pair dictionary, etc.

[0058] Storing the file I / O usage information acquired each time helps to create a program's file usage history, which in turn facilitates troubleshooting issues such as abnormal file usage. Storing file I / O usage information in a key-value dictionary not only allows for quick and accurate retrieval of individual file I / O usage information for different files, but also improves the maintainability of this information.

[0059] In one example, this disclosure should delete all file I / O usage information for a file currently stored at an appropriate time. The timing of deleting all file I / O usage information for a file can be set after the breakpoint is triggered by the file close method. For example, when the breakpoint setting method in GDB determines that the name of the currently triggering breakpoint method is file close, it can first obtain the file identifier. At this time, the file close method suspends execution. After the user outputs all key-value pairs corresponding to the file identifier to the target location in an appropriate manner, the breakpoint setting method in GDB can perform the operation of deleting all key-value pairs corresponding to the file identifier in the key-value pair dictionary. After that, the file close method can be resumed and the program continues to execute.

[0060] The method for setting breakpoints in GDB disclosed herein can be expressed in the form of the following pseudocode:

[0061]

[0062]

[0063]

[0064] It should be noted that in the pseudocode above, file I / O usage information is not stored in ioinfo for the file closing operation type. This disclosure does not preclude the possibility of storing file I / O usage information in ioinfo for the file closing operation type. For example, the file identifier and file closing flag can be stored in ioinfo as key-value pairs. Furthermore, the operation of deleting all key-value pairs with fileIdentifier as the key in ioinfo in this disclosure can be performed in other ways, such as by the user manually entering and executing it in the GDB command line. This disclosure does not limit this.

[0065] S103. Output the file I / O usage information obtained above to the target location.

[0066] In this disclosure, the target location refers to a carrier that can display file I / O usage information, such as a printer or the GDB console. The GDB console can be the GDB operating interface (such as an interface that includes command lines).

[0067] In one example, this disclosure allows the use of a custom GDB command to output all or part of the currently stored file I / O usage information to the GDB console. For instance, when a user needs to view the program's usage of a specific file, the user can enter this custom GDB command in the GDB console command line. The custom GDB command will then be executed, and the corresponding file I / O usage information will be output to the GDB console. In a more concrete example, a pre-registered breakpoint based on a file I / O operation type is triggered by a file I / O operation in the program. If the program pauses execution after calling GDB's breakpoint setting method, the user can enter this custom GDB command in the GDB console command line. The execution of this custom GDB command will output the corresponding file I / O usage information to the GDB console. The input parameters of this custom GDB command typically include a file identifier, but may also include a file name. If the input parameters do not include a file identifier, the custom GDB command can find the file identifier using the file name. By using custom GDB commands to output file I / O usage information to the GDB console, program developers / debuggers can view file I / O usage information at any time, thus facilitating the troubleshooting of file usage anomalies and other issues in the program.

[0068] In one example, the custom GDB command in this disclosure can first determine whether the currently stored file I / O usage information contains a key-value pair corresponding to a file identifier. For example, the custom GDB command can first determine whether the key-value pair dictionary stores a key-value pair corresponding to a file identifier. If no key-value pair corresponding to the file identifier is stored, the custom GDB command outputs information indicating that the file I / O usage information recorded for the file identifier is empty (such as "no file I / O operation recorded"). If a key-value pair corresponding to the file identifier is stored, the custom GDB command outputs all currently stored file I / O usage information to the GDB console.

[0069] A more concrete example is that this disclosure can rewrite existing calling methods (such as the invoke method) so that custom GDB commands can output the obtained file I / O usage information to the GDB console in a predetermined format through the rewritten calling method. For example, a custom GDB command can use the rewritten calling method (such as the rewritten invoke method) to determine whether the current key-value pair set (such as the key-value pair dictionary ioinfo) contains a key-value pair corresponding to a file identifier. If the result of the determination is that the set does not contain a key-value pair corresponding to the file identifier (i.e., the result of the determination is empty), the rewritten calling method outputs a message indicating that the recorded file I / O usage information is empty (such as "no file I / O operation recorded"). If the result of the determination is that the set contains a key-value pair corresponding to the file identifier (i.e., the result of the determination is not empty), the rewritten calling method outputs all currently stored file I / O usage information based on the file identifier to the GDB console in a predetermined format, thereby enabling the custom GDB command to achieve formatted output of file I / O usage information.

[0070] By using a rewritten calling method (such as a rewritten invoke method) in a custom GDB command to check whether the currently stored file I / O usage information is empty, it is possible to effectively avoid attempting to output file I / O usage information without any valid data. On the one hand, this allows users to clearly know whether file I / O usage information has been recorded; on the other hand, it helps avoid potential errors during output, such as null pointer references and incorrect data formats. Formatting the output of file I / O usage information improves readability, thereby enabling program developers / debuggers to quickly and accurately understand the specific details of file I / O operations.

[0071] The custom GDB commands disclosed herein can be expressed in the form of the following pseudocode:

[0072]

[0073] In one example, a specific implementation of the method disclosed herein for viewing file input and output usage is as follows: Figure 2 As shown.

[0074] Figure 2 In this method, we begin to debug a program using GDB. Before debugging the program, we load an extended GDB plugin, which performs breakpoint registration operations for open file operation type, read file operation type, write file operation type, and close file operation type.

[0075] The file opening method (also called the file opening function, which will be used as an example below) in the program to be debugged. Figure 2 (Continuing the explanation) When executed, breakpoints registered for the open file operation type are triggered, program execution is interrupted, and GDB methods for setting breakpoints (such as the stop method; the stop method will be used as an example below) are activated. Figure 2 (Continuing the explanation) When the `stop` method determines that the name of the method triggering the breakpoint is `open`, it retrieves the `pathname` parameter from the input parameters of the `open` method. This `pathname` parameter includes not only the file name but also the file's storage path. The `stop` method allows the `open` method to proceed until it completes. After the `open` method finishes execution, the `stop` method reads the data in the `rax` register to obtain the return value of the `open` method, which is the file identifier (`fileIdentifier`) assigned by the system to the currently opened file. The `stop` method can use the `fileIdentifier` as the key and `pathname` as the value, storing this key-value pair in the key-value dictionary `ioinfo`.

[0076] The file reading method (also called a file reading function; the following example uses the file reading method) in the program to be debugged. Figure 2 (Continuing the explanation) When executed, the breakpoint registered for the file read operation type is triggered, program execution is interrupted, and the `stop` method in GDB is executed. This `stop` method, upon determining that the name of the currently triggering breakpoint is `read`, retrieves the file identifier `fileIdentifier`, the buffer start position `buffer`, and the buffer size `nbytes` from the input parameters of the file read method. Then, the `stop` method uses the file identifier `fileIdentifier` as the key and `buffer`, `nbytes`, and the read flag (i.e., `buffer` and `nbytes` are set to the read flag) as the values, storing this key-value pair in the key-value pair dictionary `ioinfo`. Users can input custom GDB commands in the GDB interface to output all key-value pairs currently stored in the `ioinfo` dictionary with the file identifier `fileIdentifier` as the key to the GDB interface, and then input a "allow" command in the GDB interface to allow the program to continue execution.

[0077] The file writing method (also called file writing function, the following example uses the file writing method) in the program to be debugged. Figure 2(Continuing the explanation) When executed, the breakpoint registered for the write file operation type is triggered, program execution is interrupted, and the `stop` method in GDB is executed. This `stop` method, upon determining that the name of the currently triggering breakpoint is `write`, retrieves the file identifier `fileIdentifier`, the buffer start position `buffer`, and the buffer size `nbytes` from the input parameters of the write file operation. Then, the `stop` method uses the file identifier `fileIdentifier` as the key and `buffer`, `nbytes`, and the write flag (i.e., `buffer` and `nbytes` are set to the write flag) as the value, storing this key-value pair in the key-value pair dictionary `ioinfo`. Users can input custom GDB commands in the GDB interface to output all key-value pairs currently stored in the `ioinfo` dictionary with the file identifier `fileIdentifier` as the key to the GDB interface, and then input a "allow" command in the GDB interface to allow the program to continue execution.

[0078] The file closing method (also called the file closing function) in the program to be debugged; the following example uses the file closing method. Figure 2 (Continuing the explanation) When executed, the breakpoint registered for the file closure operation type is triggered, the program execution is interrupted, and the stop method in GDB is executed. When the stop method determines that the name of the method that triggered the breakpoint is close, it obtains the file identifier fileIdentifier from the input parameters of the file closure method. Then, the stop method can use the file identifier fileIdentifier as the key to delete all key-value pairs in the key-value pair dictionary ioinfo that use the file identifier fileIdentifier as the key, thus ending the monitoring process of the file IO usage of this file.

[0079] Exemplary device

[0080] Figure 3 This is a schematic diagram of a specific embodiment of the device for implementing parameter monitoring according to the present disclosure. The device of this embodiment can be used to implement the present disclosure. Figure 1 and Figure 2 The method embodiment shown. For example... Figure 3 The device shown mainly includes: a breakpoint registration module 300, a processing logic module 301, and an output control module 302. The following describes each module of the device.

[0081] The breakpoint registration module 300 is primarily used to perform breakpoint registration based on file I / O operation types using extended GDB plugins. For example, the breakpoint registration module 300 uses an extended GNU debugger plugin for open file operation types and performs breakpoint registration based on open file operation types. As another example, the breakpoint registration module 300 uses an extended GNU debugger plugin for read file operation types and performs breakpoint registration based on read file operation types. As yet another example, the breakpoint registration module 300 uses an extended GNU debugger plugin for write file operation types and performs breakpoint registration based on write file operation types. As yet another example, the breakpoint registration module 300 uses an extended GNU debugger plugin for close file operation types and performs breakpoint registration based on close file operation types. More specific operations performed by the breakpoint registration module 300 can be found in the above description regarding... Figure 1 and Figure 2 The description of [the subject] will not be elaborated here.

[0082] The processing logic module 301 is mainly used to call the breakpoint-setting methods in GDB when a pre-registered breakpoint based on a file I / O operation type is triggered by a file I / O operation in the program during program execution. These breakpoint-setting methods are the methods executed by GDB when a breakpoint is triggered. The breakpoint-setting methods determine the type of the file I / O operation that triggered the breakpoint and, based on that type, obtain the corresponding file I / O usage information.

[0083] In one example, file I / O usage information may include: file identifier, file name, buffer start position, and part or all of the buffer size. The method setting a breakpoint can determine the type of file I / O operation triggered by the method name, and obtain the corresponding file I / O usage information based on the input parameters of the method. For example, if the breakpoint setting method determines that the name of the method triggering the breakpoint is "open file," it determines that the file I / O operation type is "open file operation," obtains the file name of the opened file from the input parameters of the method, and allows the method to continue execution by issuing a "allow execution" command, thus obtaining the file identifier returned by the method. As another example, if the breakpoint setting method determines that the name of the method triggering the breakpoint is "read file," it determines that the file I / O operation type is "read file operation," and obtains the file identifier, buffer start position, and buffer size from the input parameters of the method. For example, when a breakpoint setting method determines that the name of the method triggering the breakpoint is "write file," it determines that the file I / O operation type of the current breakpoint is a "write file" operation. The breakpoint setting method then retrieves the file identifier, the starting position of the buffer, and the size of the buffer from the input parameters of the method triggering the breakpoint. Similarly, when a breakpoint setting method determines that the name of the current breakpoint is "close file," it determines that the file I / O operation type of the current breakpoint is a "close file" operation. The breakpoint setting method then retrieves the file identifier from the input parameters of the method triggering the breakpoint.

[0084] In one example, file I / O usage information also includes at least one of a read flag and a write flag. In one application scenario, if the method setting the breakpoint determines that the name of the currently triggering breakpoint is "read file," the file identifier obtained from the input parameters, the start position of the buffer, and the size of the buffer can be set in the read flag. In another application scenario, if the method setting the breakpoint determines that the name of the currently triggering breakpoint is "write file," the file identifier obtained from the input parameters, the start position of the buffer, and the size of the buffer can be set in the write flag.

[0085] In one example, the method for setting breakpoints can determine the type of file I / O operation that triggered the breakpoint, and after obtaining the corresponding file I / O usage information based on that type, it can store the obtained file I / O usage information. For example, the method for setting breakpoints can use the file identifier as the key, and the file name, the starting position of the buffer, the size of the buffer, the read flag, and a portion of the write flag as the values, storing them in a key-value dictionary.

[0086] For more specific operations performed by the processing logic module 301, please refer to the above-mentioned... Figure 1 and Figure 2 The description of [the subject] will not be elaborated here.

[0087] The output control module 302 is mainly used to output the file I / O usage information obtained by the processing logic module 301 to the target location. For example, the output control module 302 uses a custom GDB command to output the stored file I / O usage information to the GDB console. The custom GNU debugger command can use a rewritten calling method to determine whether the key-value pair dictionary stores the key-value pair corresponding to the file identifier obtained by the processing logic module 301. If no key-value pair corresponding to the obtained file identifier is stored, the rewritten calling method outputs information indicating that the recorded file I / O usage information is empty. If the key-value pair corresponding to the obtained file identifier is stored, the rewritten calling method outputs the key-value pair corresponding to the obtained file identifier to the GDB console based on a predetermined format. More specific operations performed by the output control module 302 can be found in the above description of... Figure 1 and Figure 2 The description of [the subject] will not be elaborated here.

[0088] Exemplary electronic devices

[0089] The following is for reference. Figure 4 To describe an electronic device according to embodiments of the present disclosure. Figure 4 A block diagram of an electronic device according to an embodiment of the present disclosure is shown. (As follows) Figure 4 As shown, the electronic device 41 includes one or more processors 411 and memory 412.

[0090] The processor 411 may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 41 to perform desired functions.

[0091] The memory 412 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may, for example, include random access memory (RAM) and / or cache memory. The non-volatile memory may, for example, include read-only memory (ROM), hard disk, and flash memory. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 411 may execute the program instructions to implement the methods for viewing file input / output usage and / or other desired functions described in the various embodiments of this disclosure above.

[0092] In one example, electronic device 41 may further include input device 413 and output device 414, etc., these components being interconnected via a bus system and / or other forms of connection mechanism (not shown). Furthermore, the input device 413 may also include, for example, a keyboard, mouse, etc. The output device 414 can output various information to the outside. The output device 414 may include, for example, a display, speaker, printer, and communication networks and their connected remote output devices, etc.

[0093] Of course, for the sake of simplicity, Figure 4 Only some of the components of the electronic device 41 relevant to this disclosure are shown, omitting components such as buses, input / output interfaces, etc. In addition, the electronic device 41 may include any other suitable components depending on the specific application.

[0094] Exemplary computer program products and computer-readable storage media

[0095] In addition to the methods and apparatus described above, embodiments of this disclosure may also be computer program products comprising computer program instructions that, when executed by a processor, cause the processor to perform the steps of the methods for viewing file input and output usage according to various embodiments of this disclosure as described in the "Exemplary Methods" section of this specification.

[0096] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this disclosure. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program source code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0097] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions that, when executed by a processor, cause the processor to perform the steps of the methods for viewing file input and output usage according to various embodiments of this disclosure as described in the "Exemplary Methods" section above.

[0098] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may, for example, include, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples (not an exhaustive list) of a readable storage medium may include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0099] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0100] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For system embodiments, since they largely correspond to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0101] The methods and apparatus of this disclosure may be implemented in many ways. For example, they may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order of steps for the methods is for illustrative purposes only, and the steps of the methods of this disclosure are not limited to the order specifically described above unless otherwise specifically stated. Furthermore, in some embodiments, this disclosure may also be implemented as a program recorded on a recording medium, the program including machine-readable instructions for implementing the methods according to this disclosure. Thus, this disclosure also covers recording media storing programs for performing the methods according to this disclosure.

[0102] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

Claims

1. A method for viewing file input and output usage, characterized in that, The method includes: Utilize the extended GNU debugger plugin to perform breakpoint registration based on file I / O operation type for at least one file I / O input / output operation type; During program execution, if a pre-registered breakpoint based on a file I / O operation type is triggered by a file I / O operation in the program, the method for setting the breakpoint in the GNU debugger is called; wherein, the method for setting the breakpoint in the GNU debugger is the method executed by the GNU debugger when the breakpoint is triggered; The method for setting breakpoints determines the type of file I / O operation that triggers the breakpoint, and obtains the corresponding file I / O usage information based on the type of file I / O operation that triggers the breakpoint. The obtained file I / O usage information is output to the target location.

2. The method according to claim 1, characterized in that, The use of the extended GNU debugger plugin for at least one file I / O input / output operation type, and the execution of breakpoint registration based on the file I / O operation type, includes at least one of the following: Utilize the extended GNU debugger plugin for open file operation types to perform breakpoint registration based on open file operation types; Utilize the extended GNU debugger plugin for file read operation types to perform breakpoint registration based on file read operation types; Utilize the extended GNU debugger plugin for write operation types to perform breakpoint registration based on write operation types; Utilize the extended GNU debugger plugin for closing file operations to perform breakpoint registration based on the closing file operation type.

3. The method according to claim 2, characterized in that, The file I / O usage information includes at least one of the following: file identifier, file name, starting position of the buffer, and size of the buffer.

4. The method according to claim 3, characterized in that, The method for setting breakpoints determines the type of file I / O operation that currently triggers the breakpoint, and obtains the corresponding file I / O usage information based on the type of file I / O operation that currently triggers the breakpoint, including: The method for setting breakpoints determines the type of file I / O operation triggered by the breakpoint based on the name of the method that triggered the breakpoint, and obtains the corresponding file I / O usage information based on the input parameters of the method that triggered the breakpoint.

5. The method according to claim 4, characterized in that, The method for setting breakpoints determines the type of file I / O operation triggered by the breakpoint based on the name of the method that triggered the breakpoint, and obtains the corresponding file I / O usage information based on the input parameters of the method that triggered the breakpoint, including: When the method for setting breakpoints determines that the name of the method that triggers the breakpoint is "open file", it determines that the type of file I / O operation of the current breakpoint is "open file operation". The method for setting breakpoints obtains the file name of the opened file from the input parameters of the method that triggers the breakpoint, and allows the method that triggers the breakpoint to continue execution through a release command, so as to obtain the file identifier returned by the method that triggers the breakpoint. When the method for setting breakpoints determines that the name of the method that triggers the breakpoint is "read file", it determines that the type of file I / O operation of the current breakpoint is "read file operation". The method for setting breakpoints obtains the file identifier, the starting position of the buffer, and the size of the buffer from the input parameters of the method that triggers the breakpoint. When the method for setting breakpoints determines that the name of the method that triggers the breakpoint is "write file", it determines that the type of file I / O operation of the current breakpoint is "write file operation". The method for setting breakpoints obtains the file identifier, the starting position of the buffer, and the size of the buffer from the input parameters of the method that triggers the breakpoint. When the method for setting breakpoints determines that the name of the method that triggers the breakpoint is "close file", it determines that the type of file I / O operation of the current breakpoint is "close file operation". The method for setting breakpoints obtains the file identifier from the input parameters of the method that triggers the breakpoint.

6. The method according to claim 5, characterized in that, The file I / O usage information also includes at least one of a read flag and a write flag; The method for setting breakpoints, based on the name of the method that currently triggers the breakpoint, determines the type of file I / O operation for that breakpoint, and obtains the corresponding file I / O usage information based on the input parameters of the method that currently triggers the breakpoint. It also includes: If the method for setting breakpoints determines that the name of the method that is currently triggering the breakpoint is "read file", then the file identifier obtained from the input parameters, the starting position of the buffer, and the size of the buffer are set in the read flag. If the method for setting breakpoints determines that the name of the method that is currently triggering the breakpoint is "write file", then the file identifier, the starting position of the buffer, and the size of the buffer obtained from the input parameters are set in the write flag.

7. The method according to claim 6, characterized in that, The method for setting breakpoints further includes determining the type of file I / O operation that triggers the breakpoint, and obtaining corresponding file I / O usage information based on the type of file I / O operation that triggers the breakpoint. Store the acquired file I / O usage information; And the storage of the acquired file I / O usage information includes: The file identifier is used as the key, and the file name, the starting position of the buffer, the size of the buffer, the read flag, and a portion of the write flag are used as values ​​to store them in a key-value dictionary.

8. The method according to claim 7, characterized in that, The step of outputting the acquired file I / O usage information to the target location includes: Use custom GNU debugger commands to output the stored file I / O usage information to the GNU debugger console.

9. The method according to claim 8, characterized in that, The step of using custom GNU debugger commands to output the stored file I / O usage information to the GNU debugger console includes: The custom GUN debugger command uses a rewritten calling method to determine whether the key-value pair dictionary stores the key-value pair corresponding to the obtained file identifier; If the key-value pair corresponding to the obtained file identifier is not stored, the rewritten calling method outputs a message indicating that the recorded file I / O usage information is empty; If the key-value pair corresponding to the obtained file identifier is stored, the rewritten invocation method outputs the key-value pair corresponding to the obtained file identifier to the GNU debugger console based on a predetermined format.

10. A computer-readable storage medium storing a computer program for performing the method of any one of claims 1-9.

11. An electronic device, the electronic device comprising: processor; Memory used to store the processor's executable instructions; The processor is configured to read the executable instructions from the memory and execute the instructions to implement the method of any one of claims 1-9.

Images