An intrusive semi-localized simulation method for system calls on target processors

Abstract

The present invention provides an intrusive semi-localized simulation method for system calls on a target processor. The localized simulation technology can be used to mark the system call entry using a custom instruction, which is not limited by the processor instruction set. According to the steps proposed by the present invention, the simulation platform is slightly modified, and new system call support can be expanded. The present invention improves the versatility and extensibility of calling local system calls on the simulation platform, and various system calls use the same shared memory, thereby improving resource utilization.

Description

Technical Field

[0001] The invention relates to the field of simulation platforms, and in particular to an intrusive semi-localized simulation method for system calls on a target processor. Background Art

[0002] In the embedded field, semi-host debugging is a debugging mechanism that passes the IO requests of the target board from the application to the host running the remote debugger. Through this mechanism, users can use common input / output interfaces in the target program, such as printf, fread, etc., to improve debugging efficiency. The interface requires the support of the runtime library and the underlying system call.

[0003] The operation of the mechanism depends on the support of the hardware emulator. With the development of simulation technology, more and more simulation platforms currently support this debugging mechanism. However, most of them rely on processor-specific instructions, such as trap instructions, to implement system calls. This method is not universal, so the simulation platform must customize semi-host debugging modules for different processor architectures, making it difficult to design a unified simulation support component.

[0004] In the simulation platform, the shortcomings of the existing semi-localized simulation technology mainly exist in two aspects: Lack of universality: There are many processor models with large differences. In the simulation platform, the semi-localized simulation technology needs to rely on the specific processor instruction set, resulting in the serious lack of universality of the existing localized simulation technology. Lack of scalability: In the existing simulation platform, the target processor needs to expand to support new system calls, and a new system call identifier needs to be customized for the processor, which makes expansion difficult. Summary of the invention

[0005] In view of the above problems, the present invention is proposed to provide an intrusive semi-local simulation method of system calls on a target processor that overcomes the above problems or at least partially solves the above problems.

[0006] According to one aspect of the present invention, an intrusive semi-localized simulation method for system calls on a target processor is provided, the simulation method comprising:

[0007] The runtime library of the target processor provides a label $SYSCall$ that can identify the system call entry and inserts a null instruction at the label address;

[0008] The runtime library provides a label $SYSBuffer$ for storing system call input messages and output messages; when processing different system calls, the content after the address of the label $SYSBuffer$ can be reused;

[0009] When the program executes a system call, before entering the entry of the system call, the runtime library identifies the type and parameter information of the system call, and writes an input message at the label $SYSBuffer$, wherein the input message includes the variable length parameter length, the system call type, and the system call parameter list;

[0010] If the variable parameter length is not 0, the variable length parameter content is written after the parameter list;

[0011] Customize a debugging instruction insn_sys as the processing entry when the system call is triggered in the debugging state. Make sure that the instruction does not conflict with the processor instruction set.

[0012] When the simulation platform is initialized, the debugging instruction insn_sys replaces the empty instruction where the $SYSCall$ of the target program is located;

[0013] After the target program is executed, when a system call is encountered, the simulation platform obtains the variable-length parameter length, system call type, fixed-length parameter list, and variable-length parameter content of the current system call from the location of the label $SYSBuffer$;

[0014] Identify the system call type, pass parameters to the local system call interface, execute the local system call, and when the system call involves a handle, establish a mapping relationship between the host and client handles;

[0015] The return value and return parameters of the executed system call are still written to the location of the label $SYSBuffer$;

[0016] The target program obtains the return value, parameters and variable-length parameter data of the system call from the label $SYSBuffer$ position to complete the system call.

[0017] Optionally, after the target program is executed, when a system call is encountered, the simulation platform obtains the variable-length parameter length, the system call type, and the fixed-length parameter list of the current system call from the location of the label $SYSBuffer$, and the variable-length parameter content specifically includes:

[0018] The address of the label $SYSBuffer$ in the system call parameter buffer area on the client is extracted by using the simulation platform symbol table module interface;

[0019] The data structure for transmitting the system call parameters includes four parts: variable-length parameter length, system call type, fixed-length parameter list, and variable-length parameter. The variable-length parameter length, system call type, and fixed-length parameter list are fixed-length data. The fixed-length data of the system call parameters pointed to by the acquired client address is transmitted to the memory space of the host machine by using the memory module interface of the simulation platform.

[0020] Parse the fixed-length data of the system call parameters, obtain the length of the variable-length parameters, and then use the simulation platform memory module interface to obtain the variable-length parameters according to the value;

[0021] Identify the type of system call, convert the obtained system call parameters into parameter types applicable to the host system call, and execute the host system call.

[0022] Optionally, the identifying of the system call type, after passing parameters to the local system call interface, executing the local system call, and when the system call involves a handle, establishing a mapping relationship between the host and client handles specifically includes:

[0023] When applying for an operation handle for a file or device on the client, a local operation handle is also applied for on the host. If the application for the local operation handle is successful, a unique mapping is established and added to the mapping relationship <virtual machine handle, local handle> structure. If the application for the local operation handle fails, no mapping relationship is established.

[0024] When the client uses the operation handle, the client operates the handle it applied for and passes it to the host. The host obtains its own handle based on the mapping relationship between the client and host handles.

[0025] Write the output message of the system call. The output message data items include the variable-length parameter length and the parameter list of the system call. If the variable-length parameter length is not 0, write the variable-length parameter content after the parameter list.

[0026] The present invention provides an intrusive semi-localized simulation method for system calls on a target processor. The method uses localized simulation technology and can use custom instructions to mark system call entries without being restricted by processor instruction sets. By making small changes to the simulation platform according to the steps proposed by the present invention, new system call support can be expanded. The present invention improves the versatility and extensibility of calling local system calls on the simulation platform, and various system calls use the same shared memory, thereby improving resource utilization.

[0027] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative work.

[0029] Figure 1 A schematic diagram of the localized system call function of the simulation platform provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0030] The exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0031] The terms "comprises" and "having" and any variations thereof in the description embodiments, claims and drawings of the present invention are intended to cover non-exclusive inclusions, for example, including a series of steps or units.

[0032] The technical solution of the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments.

[0033] like Figure 1 As shown, an intrusive semi-localized simulation method for system calls on a target processor, the simulation method comprising:

[0034] The runtime library of the target processor provides a label $SYSCall$ that can identify the system call entry and inserts a null instruction at the label address.

[0035] The runtime library provides a label $SYSBuffer$ for storing system call input and output messages; when processing different system calls, the content after the address of the label $SYSBuffer$ can be reused.

[0036] When the program executes a system call, before entering the entry of the system call, the runtime library identifies the type and parameter information of the system call, and writes the input message at the label $SYSBuffer$. The input message includes the variable-length parameter length, the system call type, and the system call parameter list.

[0037] If the variable parameter length is not 0, the variable length parameter content is written after the parameter list.

[0038] Customize a debugging instruction insn_sys as the processing entry when the system call is triggered in the debugging state. Make sure that the instruction does not conflict with the processor instruction set.

[0039] When the simulation platform is initialized, the debugging instruction insn_sys replaces the empty instruction where the $SYSCall$ of the target program is located.

[0040] After the target program is executed, when a system call is encountered, the simulation platform obtains the variable-length parameter length, system call type, fixed-length parameter list, and variable-length parameter content of the current system call from the location of the label $SYSBuffer$.

[0041] The address of the label $SYSBuffer$ of the system call parameter buffer on the client is extracted using the simulation platform symbol table module interface.

[0042] The data structure for transmitting system call parameters includes four parts: variable-length parameter length, system call type, fixed-length parameter list, and variable-length parameter. Among them, the variable-length parameter length, system call type, and fixed-length parameter list are fixed-length data. The simulation platform memory module interface is used to transmit the fixed-length data of the system call parameters pointed to by the acquired client address to the memory space of the host machine.

[0043] Parse the fixed-length data of the system call parameters, obtain the length of the variable-length parameters, and then use the simulation platform memory module interface to obtain the variable-length parameters based on the value.

[0044] Identify the type of system call, convert the obtained system call parameters into parameter types applicable to the host system call, and execute the host system call.

[0045] Identify the system call type, pass parameters to the local system call interface, execute the local system call, and when the system call involves a handle, establish a mapping relationship between the host and client handles.

[0046] When an operation handle is requested for a file or device on the client, a local operation handle is also requested on the host. If the application for the local operation handle is successful, a unique mapping is established and added to the mapping relationship <virtual machine handle, local handle> structure. If the application for the local operation handle fails, no mapping relationship is established.

[0047] When the client uses the operation handle, the client operates the handle it applied for and passes it to the host. The host obtains its own handle based on the mapping relationship between the client and host handles.

[0048] Write the output message of the system call. The output message data items include the variable-length parameter length and the parameter list of the system call. If the variable-length parameter length is not 0, write the variable-length parameter content after the parameter list.

[0049] The return value and return parameters of the executed system call are still written to the location of the label $SYSBuffer$;

[0050] The target program obtains the return value, parameters and variable-length parameter data of the system call from the label $SYSBuffer$ position to complete the system call.

[0051] Beneficial effects: The technical problem to be solved by the present invention is to overcome the shortcomings of the prior art. Traditional technical solutions mostly rely on specific instructions of the processor itself, such as trap instructions, to implement system calls. Such methods are not universal, so that the simulation platform must customize semi-host debugging modules for different processor architectures, and it is difficult to design a unified simulation support component. To this end, a semi-local simulation technology for implementing system calls in the simulation environment of the target processor is provided, providing a unified implementation method for the simulation platform to implement semi-local system calls.

[0052] The above specific implementation methods further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above are only specific implementation methods of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. An intrusive semi-localized simulation method for system calls on a target processor, characterized in that: The simulation method comprises: The runtime library of the target processor provides a label $SYSCall$ that can identify the system call entry and inserts a null instruction at the label address; The runtime library provides a label $SYSBuffer$ for storing system call input messages and output messages; when processing different system calls, the content after the address of the label $SYSBuffer$ can be reused; When the program executes a system call, before entering the entry of the system call, the runtime library identifies the type and parameter information of the system call, and writes an input message at the label $SYSBuffer$, wherein the input message includes the variable length parameter length, the system call type, and the system call parameter list; If the variable parameter length is not 0, the variable length parameter is written after the parameter list; Customize a debugging instruction insn_sys as the processing entry when the system call is triggered in the debugging state. Make sure that the instruction does not conflict with the processor instruction set. When the simulation platform is initialized, the debugging instruction insn_sys replaces the empty instruction where the $SYSCall$ of the target program is located; After the target program is executed, when a system call is encountered, the simulation platform obtains the variable-length parameter length, system call type, fixed-length parameter list, and variable-length parameter of the current system call from the location of the label $SYSBuffer$; Identify the system call type, pass parameters to the local system call interface, execute the local system call, and when the system call involves a handle, establish a mapping relationship between the host and client handles; The return value and return parameters of the executed system call are still written to the location of the label $SYSBuffer$; The target program obtains the return value, parameters and variable-length parameter data of the system call from the label $SYSBuffer$ position to complete the system call.

2. The intrusive semi-local simulation method for system calls on a target processor according to claim 1, characterized in that: After the target program is executed, when a system call is encountered, the simulation platform obtains the variable-length parameter length, system call type, and fixed-length parameter list of the current system call from the location of the label $SYSBuffer$. The variable-length parameters specifically include: The address of the label $SYSBuffer$ in the system call parameter buffer area on the client is extracted by using the simulation platform symbol table module interface; The data structure for transmitting the system call parameters includes four parts: variable-length parameter length, system call type, fixed-length parameter list, and variable-length parameter. If the variable-length parameter length, system call type, and fixed-length parameter list are fixed-length data, the fixed-length data of the system call parameters pointed to by the acquired client address is transmitted to the memory space of the host machine by using the simulation platform memory module interface. Parse the fixed-length data of the system call parameters, obtain the length of the variable-length parameters, and then use the simulation platform memory module interface to obtain the variable-length parameters according to the value; Identify the type of system call, convert the obtained system call parameters into parameter types applicable to the host system call, and execute the host system call.

3. The intrusive semi-local simulation method for system calls on a target processor according to claim 1, characterized in that: The identifying system call type, after inputting parameters into the local system call interface, executing the local system call, when the system call involves a handle, establishing a mapping relationship between the host and client handles specifically includes: When applying for an operation handle for a file or device on the client, a local operation handle is also applied for on the host. If the application for the local operation handle is successful, a unique mapping is established and added to the mapping relationship <virtual machine handle, local handle> structure. If the application for the local operation handle fails, no mapping relationship is established. When the client uses the operation handle, the client operates the handle it applied for and passes it to the host. The host obtains its own handle based on the mapping relationship between the client and host handles. Write the output message of the system call. The output message data items include the variable-length parameter length and the parameter list of the system call. If the variable-length parameter length is not 0, write the variable-length parameter after the parameter list.

Images