CN101937392A - A Dynamic Defect Detection Method for Embedded Software - Google Patents

Abstract

The invention provides a dynamic defect detection method for precise embedded software. The embedded software comprises a test proxy module and a client module which are communicated with each other through a network, wherein a test proxy runs on a target machine to detect a detected program, sample and extract needed data and information and send the data and information to a client; the test proxy comprises a sampling module and the test proxy module; the sampling module is loaded to a kernel space in a mode of a Linux kernel module to operate a power management unit (PMU) register and sample an instruction address; the test proxy module is used for the proxy of interaction between the kernel module and the client, receiving the request, configuration and the like of the client, correspondingly setting the kernel module, reading sample data from the kernel module and sending the sample data to the client; and the client is developed and integrated to a GDIX embedded software test platform in a form of Eclipse plug-in. In the method, through the test proxy module and the client module, an embedded software dynamic defect detection service is provided and the processing and display of test result data are performed on line in real time.

Description

A Dynamic Defect Detection Method for Embedded Software

technical field

The invention belongs to the field of embedded software testing, in particular to a method for dynamic defect detection based on embedded software.

technical background

In the field of digital home appliances, embedded systems need to support the playback of a large number of high-definition video and audio, and provide high-definition audio-visual entertainment and information services. Then embedded software is bound to have a lot of CPU operations such as encoding and decoding, and becomes CPU-consuming software. Therefore, the efficiency of runtime becomes one of the key issues to improve the performance of embedded software.

In an embedded system, various resources are relatively very limited. Embedded software is closely integrated with hardware. To write efficient embedded software, many hardware-related issues need to be considered, such as how to efficiently use RAM and how to use I reasonably. /O port, etc. However, many problems are closely related to the hardware environment of the target system, and it is difficult or impossible for developers to solve them with static coding, such as frequent data cache misses caused by non-locality of data, compiler and processor pipelines, etc. Caused branch prediction failure, etc., but the generation of these events can affect the operating efficiency of embedded software. Branch prediction failure will cause pipeline flushing, wasting a lot of clock cycles, and the performance of microprocessor out-of-order execution cannot be exerted; due to the difference between processor frequency and memory access speed, data cache miss will cause relatively slow memory A large number of visits, reducing operating efficiency; and so on.

These defects that affect the efficiency of instruction execution cannot be eliminated by statically checking the code. They may not be caused by the code itself, but due to changes in compilation or hardware characteristics. For different hardware platforms, different compilations The problem will be different in different tool chains. There is no uniform and static method to solve the problem. The only way is to use a dynamic method to count and locate the key points of defects during the running of the software, so that developers can Optimize the implementation of the code according to the detection results, reduce or eliminate the impact of defects, and improve the operating efficiency of embedded software.

At present, there are few researches on dynamic defect detection technology. There is a kind of detection of faults on the software and hardware platform itself using I/O-EFA, which cannot solve the software defects related to hardware well; the source code instrumentation technology can find abnormal behavior in the software, However, for unforeseen abnormal behavior and detection of hardware-related problems, there are great limitations; there is open source software OProfile, but it requires the support of the Linux kernel, and the OProfile option needs to be specified in the process of compiling the kernel, and it requires The test results cannot be obtained until the program under test is finished running, and real-time online testing cannot be performed.

Contents of the invention

The purpose of the present invention is to overcome the shortcomings that current related tools cannot perform dynamic and real-time defect detection and the accuracy of test results is not high, and propose an accurate dynamic defect detection method for embedded software.

In order to realize the purpose of the invention, the technical scheme adopted is as follows:

An embedded software dynamic defect detection method, which is divided into two parts: a client and a test agent, the client is set in a development machine, the test agent is set in a linux target machine, and the client and the test agent are implemented through the network Communication, so that the sample data collected by the test agent is sent to the client in real time through the network for analysis and real-time update display.

In the above technical solution, the test agent runs on the embedded operating system or the target board of the target machine. It includes a sampling module for collecting and counting sample data and a test agent module for transmitting sample data.

The sampling module runs in the kernel space of embedded Linux, is the core part of the test agent, is responsible for the collection of defect sample data, and provides an interface for the test agent module to configure and read, and is divided into a PMU configuration module and an interrupt processing module , control module, proc file system interface, configuration table and sample cache.

The PMU configuration module is based on the PMU hardware unit supported by microprocessing, encapsulates the operation details of the PMU hardware unit, and provides an abstract access interface for upper layer calls;

The interrupt processing module is to capture and process various hardware event interrupts that occur when the system is running, sample the instruction addresses that cause these events, organize them into samples and store them in the sample cache;

The control module interacts with the test agent module through the proc file system, receives the event configuration information, maps it to the PMU event code through the configuration table, writes the PMU event selection unit through the PMU configuration module, and returns to the sample cache through the proc file system interface sample data information;

The proc file system interface is a commonly used interface for interaction between kernel space and user space, and is also an interface for interaction between the test agent module and the sampling module. The sampling module provides the sample data access interface to the test agent module through it, and at the same time, the test agent module uses it as the configuration interface of the sampling module;

The configuration table belongs to the shared structure of the kernel, is a hash table structure that is convenient for searching, and maintains the correspondence between event configuration information and PMU hardware unit event codes;

The sample cache is represented by a circular queue, which is used to store the sample data information generated by the interrupt processing module for the test agent module to read and send to the client of the development machine through the proc file system interface.

The test agent module runs in the user space of embedded Linux, is responsible for monitoring a specific port, provides embedded defect detection and testing services, interacts with the client that initiates the connection, reads the sample data collected by the sampling module, and sends it in real time through the network to the client. The test agent module includes Slave pool, connection allocator, worker thread and service process.

Described Slave pool is a simple process pool specially implemented for the test agent module, Slave pool communicates with service process through Domain Socket, transfers socket handle, and understands their state;

The connection allocator is responsible for listening to the service port, receiving the connection request and calling the interface of the Slave pool to allocate and manage the request;

The working thread reads the test sample data information from the sample cache of the sampling module through the proc file system interface, and sends it to the client through the client connection socket;

The service process is responsible for interacting with the client and manipulating the data shared with the worker threads. When it receives the socket handle connected to the client sent by the connection allocator, the service process enters a loop, selects the handle and performs timeout processing, and at the same time interacts with the client and operates on shared data.

The client runs in the form of an Eclipse plug-in in the host development machine with rich hardware and software resources, and interacts with the test agent module through the network, and sends control commands or executable files compiled through the cross-compilation tool chain to the target machine The client test agent module, the client includes a data collector and a data processing module, the data collector is responsible for receiving sample data for the client, and handing it over to the data processing module for data processing and analysis. The data processing module analyzes and processes the data according to a certain analytical algorithm, and updates the corresponding components on the GUI. On the development machine, the symbol resolver is also running to provide symbol resolution services for client plug-ins.

The data collector and the data processing module collect data from the test agent, and at the same time, convert the format of the received binary data, mainly to adjust the byte order, and convert the data of the little-endian byte order into a big-endian Java structures in byte order and stored in memory.

The invention implements real-time online dynamic defect detection on the embedded software through the client end and the test agent end, and can dynamically and visually display the test data to the test user.

Description of drawings

Figure 1 shows the cross-test model.

Figure 2 is a framework diagram of embedded software dynamic defect detection.

Figure 3 is a frame diagram of the test agent module.

Figure 4 is a structural diagram of the sampling module.

Figure 5 is a frame diagram of the client.

Fig. 6 is a functional diagram of the client symbol parsing server.

FIG. 7 is a process diagram of data processing at the client control layer.

Specific implementation method

The present invention will be further described below in conjunction with the accompanying drawings.

In order to realize real-time online defect detection, the present invention adopts a test mode based on cross-test, as shown in Figure 1, the test tool runs on a host machine with rich software and hardware configuration, and after it processes the program to be tested, it runs on the Test information is generated on the target machine with relatively insufficient hardware and software resources, and is transmitted to the host machine by the test agent through a certain communication connection, and the test results are received and displayed by the test tool.

The overall frame diagram of the embedded software dynamic defect detection tool in the present invention is shown in FIG. 2 . The design follows the cross-test mode, which is divided into a client and a test agent. The client runs on the development machine, and the test agent is divided into a test agent module and a kernel sampling module. The client runs in the JRE environment of the development machine in the form of an eclipse plug-in, and uses SWT/JFACE for GUI design. After the developer cross-compiles the program, he can use the client to upload the executable file to the test agent, and inform the test agent which defect events need to be detected. The test agent module receives the executable file and runs it as a child process, and at the same time writes various necessary configuration information into the kernel module through the character device interface. The kernel module receives the configuration information through the character device, and reads and writes the PMU hardware unit of the microprocessor, configures various registers, starts/stops the PMU interrupt and other operations according to the configuration information; the PMU interrupt processing is responsible for specific sampling work, Sampling the user state stack saved when the interrupt occurs, extracting the pc register value, organizing it into a sample data structure and saving it in the sample cache. After the test proxy module is configured, it reads the sample cache through the character device and sends it to the client data receiving module in real time. The client parses the sample data to obtain a series of instruction addresses and events. By calling the address resolution service, the client matches the instruction address with the specific source code line, generates rendering information, and delivers it to the rendering module. The rendering module updates the GUI, allowing developers to intuitively obtain the information of dynamic defect events from the source code.

The test agent runs on the embedded operating system of the target machine or on the target board. It includes a sampling module for collecting and counting sample data and a test agent module for transmitting sample data. The test proxy module is responsible for acting as an agent for the kernel module to interact with the client, receive client requests and configurations, etc., make corresponding settings for the kernel module, and read sample data from the kernel module and send it to the client. Its structure is shown in Figure 3. Including Slave pool, connection allocator, worker thread and service process, said connection allocator handles request and request queue for Dispatcher.

When Dispatcher receives a client connection, it receives the requested service type from the client, generates a request structure, puts it in the request queue, and starts scheduling the existing requests in the queue, and takes out a request to the Slave pool to process. Slave pool generates corresponding service process according to the Request type received, because what the present invention is aimed at is defect detection, described service process is also defect detection service process. The defect detection service process has only one service state, that is, the defect detection service.

The service process is responsible for further interaction with the client and processing specific service requests. For defect detection, there are established service processes as follows:

(1) Receive the defect event sent by the client, convert it into an event code that can be recognized by the PMU, and write it into the op_conf interface of the sampling module;

(2) Receive the cross-compiled executable file sent by the client and save it in the local file system of the target machine;

(3) Receive the data request command sent by the client, start the executable file received in the previous step as the subprocess to be tested, and write its pid into the op_ctr interface of the sampling module;

(4) Start the worker thread. Wait for the client to send a command, and at the same time, wait for the subprocess under test to end by registering the SIGCHLD signal processing function. When the sub-process under test ends, in the signal processing function, write 0 to the op_ctr device of the sampling module, and stop the work of the sampling module.

Since the service process needs to wait for the end of the sub-process under test in order to stop the work of the sampling module, it is done by writing 0 to op_ctr. This operation needs to flush the kernel sample cache, which may cause sleep and wait for the read process of op_data to wake up. . If the service process is responsible for both stopping the sampling module and reading sample data, a deadlock will occur, and the service process may be in a sleep state all the time. Threads under Linux exist as independent scheduling units, so the read operation of the worker thread will wake up the service process to work normally.

The sampling module of the test agent is loaded into the kernel space in the form of a Linux kernel module, operates the PMU register, and samples the instruction address. Its structure is shown in Figure 4.

When the sampling module is loaded, three character devices are created under /dev. Provide the interactive interface between the user space process and the module. The module is responsible for sampling the instruction address of the program under test. The obtained address and defect event structure are called samples, which are placed in the sample cache. When the test agent worker process reads and writes these devices, it may cause blocking and sleep. There are two waiting queues in the sampling module: wait_for_read and sync_queue. When the process reads the sample cache through the op_data device, but the cache is empty, the process will sleep on the wait_for_read queue until the interrupt processing module adds new samples to the cache to make the cache non-empty, then wakes up the sleep process, making The process reads the sample data; when the process tries to make the sampling module stop sampling, it needs to write to op_ctr. At this time, it needs to flush the sample buffer so that all the remaining samples in the buffer are read. If the cache is not empty, it needs to sleep on the sync_queue until the cache is empty, then the reading process wakes up the sleeping process on the sync_queue to flush the cache. A configuration table is also maintained in the sampling module. After the module converts the configuration information of the module from the user space into the configuration information for reading and writing the PMU, it is stored in the configuration table.

The client module is developed in the form of an Eclipse plug-in and integrated into the GDIX embedded software test platform, as shown in Figure 5, designed according to the MVC pattern, namely the Model-View-Control (Model-View-Control) pattern, and the entire The client runs on the JRE as a plug-in. On the Linux system of the development machine, a symbol parser is running at the same time to provide symbol parsing services for client plug-ins. The developer compiles the source code into an executable file using the cross-compilation tool chain, and passes it to the test agent through the operation of the view layer, and after sending the configuration information, the source file can be opened from the engineering view to the editing area, and the To mark the defect event on the source code.

The model layer provides several basic data models for the client, including address information required for symbol analysis, structured symbol information for analyzing byte stream data conversion, and rendering information required for updating GUI;

In the control layer, the client controls and tests the network connection of the agent, sends and receives network data, analyzes and renders the received byte stream data. In the process of analyzing and rendering, it is necessary to analyze the address symbol, and match the instruction address with the source file and the code line, so as to help developers find the problem; among them, the symbol analysis module is independently formed into a symbol resolver on the client side, through The local network communicates with the client, and the interaction between the symbol analysis server and the client control layer is shown in Figure 6. When the rendering module of the control layer needs to analyze the instruction address in the obtained sample, if the mapping table has not been obtained, the connection The symbol analysis server informs the server of the path of the executable file to be analyzed. The latter reads the ELF executable file on the corresponding path to obtain the debugging information of the address-code line mapping recorded in it, and the symbol analysis server stores the mapping relationship as (address, file name, line number) triplet An array of , sent to the client rendering module for use. Figure 7 clearly illustrates the process of data processing at the control layer. The advantage of using three threads and two-level cache for collaboration is to alleviate the speed difference between network data collection, analysis and rendering, making network access and GUI response smoother fast.

The presentation layer is responsible for displaying data in the MVC pattern. It uses the extension point mechanism of Eclipse to extend Eclipse and implement functions in the form of plug-ins.

Claims (8)

1. A dynamic defect detection method for embedded software, which is completed by the joint cooperation of the client and the test agent, the client is set in the development machine, the test agent is set in the target machine, the client and the test agent Communicate through the network, so that the sample data collected by the test agent is sent to the client through the network in real time for analysis and real-time update display; The test agent includes a sampling module for collecting and counting sample data and a test agent module for sample data transmission; It is characterized in that: the sampling module is divided into a PMU configuration module, an interrupt processing module, a control module, a proc file system interface, a configuration table and a sample cache; The PMU configuration module is based on the PMU hardware unit supported by microprocessing, encapsulates the operation details of the PMU hardware unit, and provides an abstract access interface for upper layer calls; The interrupt processing module is to capture and process various hardware event interrupts that occur when the system is running, sample the instruction addresses that cause these events, organize them into samples and store them in the sample cache; The control module interacts with the test agent module through the proc file system interface, receives the event configuration information, maps it to the PMU event code through the configuration table, writes the PMU event selection unit through the PMU configuration module, and returns to the sample cache through the proc file system interface sample data information; Described proc file system interface is the interface that test proxy module and sampling module interact, sampling module provides sample data access interface to test proxy module by it, meanwhile, test proxy module uses it as the configuration interface of sampling module; The configuration table is a hash table structure that is convenient for searching, and maintains the correspondence between event configuration information and PMU hardware unit event codes; The sample cache is represented by a circular queue, which is used to store the sample data information generated by the interrupt processing module for the test agent module to read and send to the client of the development machine through the proc file system interface; The test agent module includes Slave pool, connection allocator, working thread and service process; Described Slave pool is a process pool that is specially implemented for testing agent module, and Slave pool communicates with service process through Domain Socket, transfers socket handle, and understands their state; The connection allocator is responsible for listening to the service port, receiving the connection request and calling the interface of the Slave pool to allocate and manage the request; The working thread reads the test sample data information from the sample cache of the sampling module through the proc file system interface, and sends it to the client through the client connection socket; The service process interacts with the client, and operates the data shared with the worker thread. When it receives the socket handle connected to the client sent by the connection allocator, the service process enters a loop, selects and Perform timeout processing, and simultaneously interact with the client and operate on shared data; The client includes a data collector and a data processing module, the data collector receives sample data for the client, and hands it over to the data processing module for data processing and analysis, and the data processing module analyzes and processes the data according to a set analysis algorithm, And update the corresponding components on the GUI. 2. The embedded software dynamic defect detection method according to claim 1, characterized in that said test agent runs on an embedded operating system or a target board of a target machine. 3. the embedded software dynamic defect detection method according to claim 2, it is characterized in that described sampling module operates in the kernel space of embedded Linux, carries out defect sample data collection, and provides interface for testing proxy module to configure and read. 4. according to the described embedded software dynamic defect detection method of claim 2 or 3, it is characterized in that described test agent module runs in the user space of embedded Linux, monitors specific port, and provides embedded defect detection test service, Interact with the client that initiated the connection, read the sample data collected by the sampling module, and send it to the client in real time through the network. 5. the embedded software dynamic defect detection method according to claim 1, it is characterized in that described client runs in the development machine with the form of Eclipse plug-in, and interacts with test agent module by network, will control order or pass through The executable file compiled by the cross-compilation toolchain is sent to the test agent module of the target machine. 6. The embedded software dynamic defect detection method according to claim 1 or 5, characterized in that said data collector and data processing module collect the data in binary format from the test agent, and format the received binary data The conversion includes adjusting the byte order, converting the little-endian data into a big-endian Java structure, and storing it in memory. 7. The embedded software dynamic defect detection method according to claim 1, characterized in that said development machine is also provided with a symbol resolver to provide symbol resolution services for client plug-ins. 8. the embedded software dynamic defect detection method according to claim 7, is characterized in that described client is developed and integrated in the GDIX embedded software testing platform with the form of Eclipse plug-in, according to model-view-control three-layer pattern Design, and the entire client runs on the JRE in the form of a plug-in; The model layer provides the client with a basic data model, including address information required for symbol analysis, structured symbol information for analyzing byte stream data conversion, and rendering information required for updating the GUI; The control layer controls the network connection between the client and the test agent, sends and receives network data, analyzes and renders the received byte stream data; The display layer is displaying data, and it uses the extension point mechanism of Eclipse to extend Eclipse and implement it in the form of plug-ins.

Images