A continuous self-checking validation framework on processor exceptions

Transcription

1 th International Symposium on Parallel and Distributed Computing A continuous self-checking validation framework on processor exceptions Tan Jian Jiangnan Institute of Computing Technology Wuxi, China tanjian108@qq.com Li Daifeng Jiangnan Institute of Computing Technology Wuxi, China @qq.com Abstract As a part of the processor function test, the exception handling mechanism checking cannot be neglected in the test plans. In the process of implementation processor exceptions test at system level, testers usually encounter two difficulties; the first one is that the exceptions stimulus cannot be automatically run; if any exception detect during the stimulus running, then the stimulus would be terminated. And the second one is that testers have to check the test results manually. These difficulties blocked the automatization of management on exceptions testing stimulus. To overcome the first difficulty, we adopt the vfork system-call to create the child process and run the stimulus in it; and we can run multiple stimulus automatically by continuously using the vfork to create child process. And in vfork it is visible to the parent process if the child process modified the global variables; on this basis, we realize the stimulus result selfchecking by automatically getting the exception of the stimulus to produce and the exception detect in fact. Integrated the methodologies, we proposed the continuous self-checking validation framework on processor exceptions. In addition, we have researched the exception handling mechanism in heterogeneous system, and successfully transplanted the exceptions validation framework in heterogeneous systems. Keywords- processor exception testing; continually capture processor exceptions; results self-checking; heterogeneous systems I. INTRODUCTION In recent years, with the processor's capabilities improving, the frequency rising, the degree of chip integration growing up, processor architecture has become increasingly complex. Processor verification and testing technology is increasingly important in the entire chip design and development phase. And the testing requirements are also increasing. Processor manufacturers and research institutions are increasingly widespread using the multi-core, many-core or heterogeneous architectures, aimed at obtaining higher performance. How to find design errors and defects in the testing phase as soon as possible is one of the major concerns. In order to find errors quickly and comprehensively, testers need to increase the coverage of testing as high as possible. As an important part of the processor test and verification, the correctness of exception handling mechanism is what we need to focus on. In order to comprehensively test the correctness of exception handling mechanism, the tester usually need to traverse all the processor exceptions. But the number of processor instructions tends to be large, such as AMD64-bit processors have more then 185 generic instructions [1], and Intel-X86 64-bit processors have more than 500 instructions [2]. Each instruction may produce different exceptions. The of exceptions and instructions will bring huge amount of testing. In addition, unlike the usual functional testing procedures, it often terminates the test program when a processor exception occurs. And the results checking need to be manual intervened. Thus, the tester can not automatically run the exception stimulus or check the results through the usual methodologies. And with the tests generating large result data, the testers have to manually check them, which consuming a lot of tests energy and time. It is not only inefficient, but also to introduce new errors. In this paper, we firstly introduce the related art about processor exception handling mechanism. Then we learn the verification technology about exceptions and interrupts. And we propose a validation framework to automatically manage the processor exception stimulus. By studying the processor exception handling mechanism in heterogeneous systems we also propose a validation framework working in the heterogeneous systems. II. RELATED WORK Processor exceptions testing and validation can be implemented by the system call signal() at the user level. Signal() is one of the OS system-calls, which handling processor exceptions and interrupts, supporting to interprocesses communication[3][4]. It can effectively manage signal generation, transmission, processing. It is the technical foundation for process communication, interruption, and switching. A. The signal handling mechanism Linux operating system introduced the signal mechanism to support the handling of the signal. It has two purposes. The first one is to inform the target process with special events. The second one is to specify the handling functions to be call when target process capturing a signal. There are five ways to generate signals in Linux, including exception occurring inside the processor. When an exception is detected by the processor during the instruction execution, it will inform the kernel. For instance, when a division instruction is to be running and its divisor is zero, then the processor will generate a SIGFPE signal; When one /16 $ IEEE DOI /ISPDC

2 load/store instruction to be executed and its source or destination address is inaccessible, then the processor will generate a SIGSGV signal. When a process receives a signal, it has three choices: (1) ignoring it; (2) calling the system default functions; (3) calling the specified signal handling functions, which are explicitly indicated by the users. When an exception occurs during the instructions execution phase, it will generate a signal. The signal will be caught and handled by the operating system. This is one of the usual way for the users carrying out processor exception testing at user-level. B. Exception handling in heterogeneous systems Heterogeneous parallel programming model is the common programming model in heterogeneous systems[5-7]. Taking the MIC processors for example, its host processor is typically a general purpose processor, and its coprocessor server as computing core which running the compact operating system[8]. The heterogeneous systems typically employ the multi-threaded programming model. When the coprocessor detect an exception, it will notify the host core with signal, and then terminate the thread running on it. The host processor must handle both the exceptions from itself and exceptions from coprocessors. Thus, the exception testing methodologies on the general purpose processor may not work in the heterogeneous systems. In our paper, We illustrated the differences between heterogeneous system exception handling mechanism and the single-core general purpose processor. We have to find a way to manage the exception stimulus in heterogeneous. C. Related work The signal handling mechanisms on processors exceptions and interrupts have been studied for many years. And the signal() had been introduced over 30 years, with no essential changes in it. The handling process of exception is almost the same as interrupt. There are lots of researches and applications based on interrupt. In our essay, we refer to the interrupt application management methodologies. Fu-Ching Yang et al who are the researchers in Taiwan's National Sun Yat-sen university, has developed an processor exception verification tool named PEVT[9], which is aimed to verify the external interrupt behaviors of microprocessors, including individual, multiple, and nested interrupts. PEVT integrates interrupt behavior simulation, interrupt behavior monitoring and verification process. It is developed for the designer to capture the external interrupt behaviors for the microprocessor under verification. It automates the management exceptions to run and verify in processors. John Regehr et al from American University of Utah, compares and contrasts threads and interrupts from the point of view of verifying the absence of race conditions [10]. They present a source-to-source transformations methodologies that turn interrupt-driven code into semantically equivalent thread-based code that can be checked by a thread verifier. In addition, the floating-point simulation software in Linux operating system is realized by means of the exception handling by the signal which causing by "device does not exist". When the CPU executes a floating point instruction, the system enters the kernel mode software simulation to calculate the result. In the end, it will return to the user program to continue. Interrupt technology and application have been widely used in X86 series processors. Intel processor interrupt vectors is reserved specifically for user to program. With the exception or interrupt handling system call return the results to the user programs, the software floatingpoint simulations in Linux system and users software interrupts do not terminate the user programs running. In object-oriented language such as C++ or JAVA, you can use try-catch catch the exceptions, such that avoiding termination of the program running. Learning from the techniques and management of exceptions or interrupts described above, we try to seek a way to automatic management technology on the exceptions stimulus. III. THE KEY TECHNOLOGIES In order to comprehensively automatic testing processor exceptions, we propose an automatic validation framework, which is implemented at the user layer. The framework is designed to continuously handling multiple exceptions which generated by the exceptions stimulus who to verify the correctness of the processor exception handling mechanism. A. Child Processes Management To solve the problems that processor exceptions stimulus will exit from the program execution when detecting exceptions, we refer to the child process creating and management which wildly used in Linux system. Linux provides three system calls to create a child process: fork, vfork, and clone. Wherein the child process created by fork() duplicates the resources from the parent process. The parent and child share the same code segment. The child process copy the data and stack segments from the parent process through the famous copy_on_write technology. And the Child process is independent of the parent. When the parent process variables change, the child will create a new copy of the page covered. It requires the dedicated communication mechanisms between the parent and child processes. The child process created by vfork() runs in the parent's address space. It is visible to the parent process with modification from the child. While an child process created, the parent process will be blocked until the child process run exec() or exit() function. The Vfork can reduce unnecessary communication cost between the parent and the child. And that is why we chose it. The clone mechanism is more powerful than the previous twos. It can not only create the child process, but also the brother ones. B. Exceptions Stimulus Automatically Running Technology In order to solve the problem that the users program terminate when exceptions occur, we use vfork() to create

3 child processes and run the exceptions stimulus in it. If the child process encounters an exception, it will return to the parent process to continue after the exception handling completed. If the child process doesn t encounter any exceptions and it will call the exit() to return to the parent process. To do that, we achieve the purpose of continuously and automatically run the exception stimulus. On this basis, we propose the exceptions continuous capture and handling technology. Its main idea shown in Fig 1.And algorithm 1 shows the detail implementation process. step1: Organize the exceptions stimulus as functions; step2: Select one exception stimuli which not running yet and jump to step3; if no then jump to step6. step3: Create a child process by calling vfork(), and run the exception stimuli in it; step4: Does the child process detects exceptions? If no, then it calls the exit() and returns to the parent process. If yes, then it will entry to the exception handling functions. step5: Go to step3 continue to run; step6: End the running and exit. Algorithm. 1. Exceptions stimulus automatically running framework As the algorithm 1 described above, we call the vfork() to create a child process and run the exception stimulus in it. When an exception occurs in the child process, then the system call the exception handler functions. When the exception handling ends,it terminates the child process and returns to the parent process. If no exception occurs, and when the child process running is completed, it calls the exit() and returns to the parent process. By doing this, we continuously run the stimulus without terminating during the whole management program running. This is the foundation to support automatically running the exception stimulus. NO created the child process for runing the stimulus Stimulus running in the child process exception stimulus sets Is there untreated test stimulus YES Test end and exit Process the Exception in exception processing function Figure 1. The automatically running framework Reccleing child processes resources Does catching exception? mal Exit form the Child Process C. Exceptions self-checking technology In order to continuously run the stimulus and verify the correctness of the exception handling mechanism, we must find out the way to check the results of stimulus. Here we propose the exceptions self-checking technology. To support the exceptions self-checking, we firstly establish the relationship between the exception stimulus and results-checksum. For example, we preset enumeration in the manage programs, its possible elements are as follow: _CHKDEFT, _RSTDEFT, _SIGILL, FPE_INV, FPE_DZE, FPE_OVF, FPE_UNF, FPE_IOV, _SIGSYS, _SIGSEGV, _SIGBUS, _SIGOTHER. If the stimuli to be produce SIGFPE signal and the divisor is ZERO, then we associate it with enum value FPE_DZE. If the stimuli to be produce SIGILL signal, then we associate it with enum value _SIGILL. In the stimulus functions, we set the result-tocheck variable to the according value, which must set before any exceptions may occur. Meanwhile, to support self-checking the results, we must know that it to be trigger which exception type. To this end, we need to rewrite the signal handler functions which all the possible exceptions involved. Specifically, in the exception handler, we set the result-type variables to the corresponding enum value. For example, we set it to _SIGSEGV in SIGSEGV signal handling function, _SIGILL in SIGILL signal handler. It should be noted that, to support the self-checking results, result-type and result-to-check variables must to be defined as global variables. In this case, any modification to the variables from child processes are visible to the parent. Thus, it is very convenient to implementing the result-tocheck presetting and result-type register, which is the key to self-checking. Again, this is why we chose vfork mechanism. Finally, in the management program we check result-tocheck and result-type variables. If they are the same, we print Testing is pass. If not, then print test failed and notify the testers. Algorithm 2 shows the ideas of results self-checking technology. step1: establish the relationship between the exception stimulus and results-checksum; step2: preset the result-to-check variables value in stimulus; step3: rewrite the signal handler functions which all the possible exceptions involved, and set the result-type variables. step4: running the stimulus in the manage program described in 3.2 section. step5: checking the result-to-check and result-type variables; step6: print the checking results. Algorithm. 2. Exception results self-checking technology D. The continuously self-checking validation framework ed with the exceptions continuous capture and handling technology and the exceptions self-checking technology, we propose the continuous self-checking validation framework on processor exceptions. Fig 2. shown its implementation process. In the framework we realized the management program with self-checking. In this framework, the exception stimulus will be organized as function lists firstly. Then, through using the exceptions continuous capture and handling technology, stimulus will be run one by one. At last, the framework checks the results. In this way, we achieve the

4 aim to continuously running the exception stimulus and checking the validation results automatically. The framework implementation is carried out at the user level. The technologies involved are general-purpose technologies which are wildly used. The exception stimulus are prepared by the C and assembly language. The framework does not require the operating system and compiler to provide additional supports. It can be realized by existing technology. So, it is a practical way to achieve automatic managing the processor exceptions. Start Construction of exception stimulus set END and EXIT Call the exceptionhandlers and modify the exception-result variables Checking the results rmaly exit from child process Start Construction of exception stimulus set in signal() setting the co-processor exception types to catch Refinement exception classify Reimplement the exception handler (Added the support for exception-result variable handling ) Organized the exception sitmulus as functions End and exit Call the coprocessor exception-handlers and modify the exceptionresult variables Checking the rsults Catch exceptions? coprocessor running the stimulus Create the threads running on coprocessors Initialized the exception checking variables and exception-result variables Is there untreated test stimulus rmaly exit from threads in signal() setting the exception types to catch Refinement exception classify Reimplement the exception handler (Added the support for exception-result variable handling ) Organized the exception sitmulus as functions Figure 2. The automatically running framework Catching exceptions? created the child process and runing the stimulus in it Initialized the exception checking variables and exception-result variables Is there untreated test stimulus E. The Framework in Heterogeneous Systems Heterogeneous systems generally take the multi-threaded programming models. When the host processor detects a processor exception, the system will catch and handle it by the signal handling mechanism, which is consistent with the general purpose processor. In the heterogeneous system, the host processor needs to handle the exceptions from the coprocessors. When the coprocessor detect an exception,the system will sent a signal to the host processor, and then the host processor to be handle the signal [11-12]. To support coprocessors exception capture and handling, the heterogeneous systems redefine the coprocessor exception types and provide a series of exception handling exceptions functions corresponding. We have known that the coprocessors exceptions will be handled by the host processor in the heterogeneous system. How do we continuously automatically capture and verify the exception stimulus which running in the coprocessors? Similar to the exception validation framework in general purpose processor, we firstly create the management program which running in the host processor; then we create the threads to be running in the coprocessor; and we run the exception stimulus in the coprocessors threads. Figure 3. The exceptions validation framework in Heterogeneous Systems To support the results self-checking, we need to preset the result-to-check in stimulus and set result-type variables in signal handing functions, which are the same way as the framework implement described above. Let s return back to exceptions validation framework in heterogeneous systems. The coprocessor run the exception stimulus and set the result-to-check variable. If the coprocessor detects an exception, it sent a signal to the host and then entry to the host to handle the signal, where the result-type variable will be set; if no exception detect, the coprocessor s thread will be ended normally and the resulttype variable will set to be _CHKDEFT. To do that, we aim at self-checking the stimulus results. The heterogeneous systems framework implementation process has been shown in Fig 3. IV. EXPERIMENTS AND ANALYSIS In the previous section we proposed the processor exceptions validation framework, and we tried this in the X86 processor and the autonomous heterogeneous manycore processor DFMC prototype system(deeply fused and heterogeneous many-core) [6]. Before the experiments, we have counted the s number of the instructions and the exceptions of the host processor and coprocessor in DFMC systems. Due to the large number of instructions, the of instructions and exceptions will be huge. Given the instructions similarity with the same type, we traverse all the possible exceptions of one type instead of the possible of the instructions and exceptions. To do that, we can cover all the check points under the instruction type. In tables 1 and table 2, we list the s of instructions and exceptions, actual, as well as s. TABLE I. Stimulus Number THE CONTRAST OF EXCEPTIONS TESTING WORKLOAD IN HOST PROCESSORS

5 Manual methodologie s framework The rates reduced % 97.82% - Speedup In the Tables, the number is the product of the instructions number and the number of the exceptions type; the actual one is the sum of exceptions which all the instructions may occur; the one is sum of exceptions which all the instruction types may occur. As can be seen from Table 1 and Table 2, we can greatly reduce the testing works without substantial loss of test coverage when we chose the ones. And by using the exceptions validation framework, we can reduce the times of the stimulus submit. We just need to submit one time in the framework and it would to be automatically running the stimulus and self-checking the results of stimulus in one single processor. In addition, the validation framework can work with self-checking results; it helps for the testers to realize checking the processors exceptions in batch. TABLE II. THE CONTRAST OF EXCEPTIONS TESTING WORKLOAD IN COPROCESSORS Stimulus Number Manual methodologies framework The rates reduced % 97.92% - Speedup As experimental results shown, compared to the traditional manual methodologies, in framework we have realized automatic submission, running in batch, selfchecking the results. To do that, it greatly reduces the workload of the tester, and greatly improves the efficiency of the test. V. CONCLUSION This paper analyses problems in processor exceptions testing. To solve the problems, we propose a continuous selfchecking validation framework on processor exceptions. Under the framework testers could automatically run multiple exceptions stimulus uninterrupted and continuously capture the exceptions which produced by the stimulus; and the framework supports testers to self-checking the testing results automatically. Under the framework, we can automatically run the stimulus and check the tests results. Therefore by running the stimulus in the framework, we can manage the exceptions stimulus as the same way as the usual functions testing stimulus. In the process of implement the processor exception testing, we found out that the workloads are great and redundant. We present one method that travels the each instructions types exceptions instead of any exceptions the instructions sets may produce. It satisfies the require of testing coverage and cut the redundant workload greatly. The exception validation framework is practical, operable, and with strong portability. We have successfully transplanted the exceptions validation framework in heterogeneous systems to test the coprocessor exceptions handling mechanism. Next, we will study the exceptions stimulus comprehensiveness with the minimal exception stimulus covering the entire processors exception handling mechanism. We will also study the framework s efficiency and performance in future. References [1] AMD64 Architecture Programmer s Manual Volume 3:General- Purpose and System Instructions, [2] Intel 64 and IA-32 Architectures Software Developer s Manual Volume 2 (2A, 2B & 2C): Instruction Set Reference, A-Z, [3] Daniel, P. Bovet, and Marco Cesati, Understanding the Linux Kernel, O REILLY, [4] Michael Kerrisk, The Linux programming interface: A Linux and UNIX System Programming Handbook, Stach Press, [5] J. Montrym, S. Oberman, J. Nickolls, and E. Lindholm, NVIDIA Tesla: A Unified Graphics and Computing Architecture, IEEE Computer Society, [6] Zheng Fang, Shen Li, Li Hongliang, and Xie Xianghui, Lightweight Error Recovery Techniques of Many-Core Processor in High Performance Computing, Journal of Computer Research and Development.52(6), pp , [7] Gao Jiangang, Research Progress and Key Technology of Manycore Processors, High Performance Computing Technology, [8] Zheng Yan, Wang Junqi, and Yin Hongwu, Research on Key Technologies of Manycore Operating System, High Performance Computing Technology, [9] Fu-Ching Yang, Wen-Kai Huang, Jing-Kun Zhong, and Ing-Jer Huang, Automatic Verification of External Interrupt Behaviors for Microprocessor Design, IEEE Transactions On Computer -Aided Design Of Integrated Circuits And Systems, VOL. 27, NO. 9, [10] John Regehr, and Nathan Cooprider, Interrupt Verification via Thread Verification, Electronic tes in Theoretical Computer Science, vol.174, pp , [11] Zilles C.B., Emer J.S., and Sohi, G.S., The Use of Multithreading for Exception Handling, Microarchitecture, MICRO-32. Proceedings. 32nd Annual International Symposium on, [12] Luo Wei, and Chen Wei, Research on ISP Modeling for Heterogeneous Processor, High Performance Computing Technology,