Embedded operating system debugging
content:
Definite to the author of the debugging program
JXIONG@ict.ac.cn) Chinese Academy of Sciences calculates the 2001 July 2001
Debug is an essential link in the development process. The general desktop operating system and the embedded operating system have a significant difference in debug environment. The former, the debugger and the debugged program are often running on the same machine, the same operating system, the debugger process is specifically provided by the operating system (PTRACE calls for early UNIX systems, today's process files System, etc.) Control, access to the debugged process. The latter (also known as a remote debugging), in order to provide the system developer, the debugger is running on the general desktop operating system, the debugged program runs in an embedded device based on a particular hardware platform. Operating system (target operating system). This brings the following issues: How to communicate with the debugger, how is the debugger generates an exception how to notify the debugger, how to control, access the debugging program, how to identify multitasking information about the debugged program and Control a particular task, how to handle some information related to the target hardware platform (such as register information of the target platform, the reverse assembly of machine code, etc.).
We introduce two remote debugging programs to see how they solve these problems. The first solution of the debugging scheme is a plug-in is to add certain functional modules to the target operating system and the debugger, both interworking information for debugging. The above problem can be solved by the following ways:
The debugger and the debugged communication debugger and the target operating system communicate with the remote debugging protocol by specifying the communication port (serial port, network card, parallel port) (the remote debugging protocol is detailed in http://rtos.ic.ac.cn/rtos / debugger /). The debugging procedure generates an exception to notify the debugger target operating system all exception handles to be turned to the communication module, inform the debugger the current exception number; the debugger displays which type exception to the user generated by the debugger. Debugger Control, this type of request to access the debug program is actually converted to access to certain registers of the address space or target platform of the debugged program, and the target operating system receives such a request can be processed directly. For a simple embedded operating system without a virtual storage concept, it is very easy to complete these tasks. The debugger identifies multi-task information about the debugged program and controls a particular task Provides a related interface by the target operating system. The target system calls the interface to provide corresponding information or control a particular task based on the request sent by the debugger, or controls a particular task, and returns the information to the debugger. Debugger Processing Information Article 2 This debugger should be able to generate an abnormality based on the abnormal identification target platform, which can be independently completed by the debugger. Supporting a variety of target platforms is a major feature of GNU GDB. In summary, this scenario requires a target operating system to provide a communication module (including simple device driver) and multi-task debug interfaces that support remote debug protocols and multi-task debug interfaces. In addition, the target operating system also needs to define a function of setting breakpoints; because some hardware platforms provide breakpoint instructions that produce specific debug traps (debug trap) to support debugging (such as x86 INT 3), while other machines do not Similar instructions are replaced with an illegal (reserved) instruction that cannot be interpreted with any one. These modules added by the target operating system are collectively referred to as "inserted", and the ROM MONITOR is called in the ROM. The general operating system also has such a module: compiles the Linux kernel running on the Alpha, SPARC or PowerPC platform, and if the KGDB switch is turned on, it is equivalent to joining the pile. Figure 1 Debugged application running in the target operating system To call the function of the setting breakpoint at the entry to generate an exception, an exception handler call debug port communication module, waiting for the debugger on the host (Host) to send information. After the two parties established a connection, the debugger waits for the user to issue a debug command, the target system waits for the debugger to generate the instruction generated according to the user command. This process is shown below. Figure 2 The essence of this scheme is to use the Exception Handler and partial interrupt processing in the software takeover target system, inserted into the debug port communication module, interact with the host's debugger. It can only work in the initialization of the target operating system, especially the debug communication port initialization, so it is generally only used to debug applications running on the target operating system, not to use to debug the target operating system, especially if you can't Debug the startup process of the target operating system. And because it must occupy a communication port of the target platform, the port of the port cannot be commissioned. The most important thing is that it must change the target operating system, so even if there is no adverse effect on the performance of the operating system in the debugging process, it will also cause a debug version that does not have a formal release. On Chip Debugging and Embedded PowerPC Background Debug Mode on-chip debugging is embedded in the processor inside the processor, which enters some special state when a certain trigger condition is met. In this state, the debugger stops running, the main unit's debugger can access various resources (registers, memory, etc.) and execute instructions by the external communication interface of the processor.
In order to achieve the host communication port and the target board debug communication interface each pin signal, the two are often connected to a simple signal conversion circuit board (as shown below). The embedded control module exists in the form of microcode monitor or pure hardware resource, including some interfaces (such as breakpoint registers, etc.). Specific products include Motorola CPU16, CPU32, Coldfire series of BDM (Background Debug Mode), Motorola PowerPC 5xx, 8xx series EPBDM (Embedded PowerPC Background Debug Mode), IBM, TI's JTAG (Joint Test Action Debug, IEEE standard), also There are onCE, MPSD, and more. The following is the MPC860 EPBDM as an example to describe the debugging method. Figure 3 The operation of the EPBDM is equivalent to the interruption and abnormality processing of the debug module embedded with the processor. The user specifies which interrupt or abnormality after setting the debug enable register (DEBUG Enable Register), the processor directly enters the debug state, not the handler of the operating system. After entering the debug state, the embedded debug module is subjected to the external debug communication interface, notifying the host debugger that is listened to the communication interface, and then the debugger can perform any system instructions (equivalent to privileges) by debugging the processor. All instructions are acquired by debugging modules, all LOAD / STORE directly access memory, cache and storage management unit (MMU) are unavailable; data registers are mapped to a special register DPDR, accessible via MTSPR and MFSPR instructions. The debugger ends the debug status to the processor to send the RFI (Return from Interrupt) instruction, and the debugger continues to run. Corresponding to the shortcomings of the pile method, the OCD does not occupy the communication port of the target platform, there is no need to modify the target operating system, which can debug the startup process of the target operating system, which greatly facilitates the system developer. The disadvantage of which is that the software workload is increased: In addition to supplementing the identification and control of the target operating system multitasking, the debugger side is required to write various types of ROM and RAM initialization for different development boards using the same chip. program. The following will debug the Linux running on the MPC860 as an example, indicating that some of the key details of the OS startup with the OCD mode will be described. First, the Linux kernel module resides in the ROM of the target board in a compressed zimage. After powering up the target board, the program is running in the specified position in the ROM to move the kernel to the RAM and decompressed, and then jump to the kernel entrance. . To debug the kernel, you must have the control of the system before the command in the ROM after power-on, that is, enter the debug state, breakpoint, so that the debugging process can be carried out. The MPC860's EPBDM provides this means. The MPC860 does not have an instruction that can generate a specific debug trap such as INT3, and the operating system kernel often has an exception handle for illegal instructions; in order to minimize interference to the kernel, it should be set to set the hardware breakpoint as possible. Instead of using illegal instructions to produce an "soft" breakpoint. Linux implements virtual memory management, embedded Linux often has this feature. The address space is completed from the real-time conversion, and the debugger cannot avoid access to the target system virtual address space, whether the debugger is not able to avoid access to the target system virtual address space, otherwise it will not be able to enter the virtual address of the program counter at the time of the breakpoint. Display the current instruction, not to mention access variables.
Due to the debugging Lookaside Buffer (Translation Lookaside Buffer), it is only possible to discharmatically handling the exception handler when the Linux kernel TLB failed. According to the page table in the virtual site, the second-level page table is accessed to obtain physical The page number is thus completing the conversion of the virtual real address. The MPC860 is set with Harvard Architecture, instructions and data cache separation (because the program's instruction segment and data segment are separated, this structure can eliminate collisions between the instructions and access data), the two TLBs are also separated Setting; however, when the TLB fails, the page table calculates the process of calculating the physical address, because the page table has only one, there is no instruction, data separation problem. The virtual address conversion This task is completely in the debugger one. Due to the above reasons, coupled with debug objects are embedded systems, generally do not have an exemplary device, and do not have to consider the memory access of the lack of pages, the increased work The amount is not big. In-depth topics Traditional debugging methods can be summarized as follows: Overpot - Program Pause - Observation Program Status - Continue to run. If the debugged is a real-time system, even if the debugger supports the batch command to avoid the user input command, the delay of the observations, the communication between the target system is also entirely missed to respond to the target platform peripheral signal. Thus, for the special debugging means provided by certain debuggers (such as GDB), the pile of the target party is improved on the original basis, called agency. When the user is debugged, the user first sets the monitor point in the debugger to specify the object name of interest in the source code expression. In order to reduce the operation of the agent analysis, the debugger converts the expression into a simple bytecode to transmit it to the agent. After the program is running, the monitoring point, wake up the agent, the agent stores the required data according to the bytecode recorded in a specific buffer (not only the end result of the expression, and the intermediate result), the procedure continues to run; this step does not need Communicate with the debugger. When the debugger is controlled again, the command can be issued to monitor the proxy query. Compared with the pile, the agent adds an analytical module that is subjected to bytecode. The corresponding target code volume is only about 3k bytes; of course, the monitoring record buffer also occupies the storage space of the target platform, but the size of the buffer It can be determined by the user during agent generation. In summary, this improvement provides a low-cost viable solution for real-time monitoring at a limited target system resource. Debugging does not only mean the breakpoint - program pause - Observation - Continue this process, often requires various means such as Profiling, Trace (Trace), and modern microprocessor technologies are these debug structures The implementation has brought difficulties. Take tracking as an example, the purpose is nothing more than logging a real program running flow; the modern processor instruction cache is integrated into the chip (especially the RISC processor), "referring to" when running instructions, most of the operation is directed inside the chip The instruction cache is performed, and only the preflection of multiple instructions can only be observed on the chip external bus, and the prefetched instructions are not necessarily executed (due to jump, etc.); in addition, the instruction is often chaos after the delivery line In order to execute, it is also a problem with how to reproduce its original order. Solutions have all three of the following:
Some processors can operate in a serial manner in addition to normal operation, and all of the finger cycles can be presented in the outer bus (equivalent to disable cache and pipeline). In this way, the tracking is much easier, and the processor performance is greatly reduced, and it is not suitable for real-time requirements. The compiler automatically inserts a designated branch and function entry into a write instruction for a particular memory area (similar to the means used by the PROFILING tool such as GPROF), which is not written directly to the memory by cache, which can be reflected outside the chip. The bus is recorded by an external logic analyzer, eventually analyzed by the host's debugging tool and combines the symbol table reconstruction program stream. This method is widely used, but after all, it is an intrusive, which has an impact on system performance. As in the on-chip debug described above, there is also a processor attached to the tracking circuit, and the "discontinuities" information (discontinuities) (branch and abnormal jump destination, etc.) of the program stream is collected. After the compression is sent to a specific port, then capture the logic analyzer to the host debug tool reconstruction program stream. The program has the smallest impact on system performance. In summary, the processor manufacturer provides a commissioned commissioning for high-grade embedded systems to high-end embedded systems to provide high-end embedded systems. In order to solve the needs of standardization in this field, some processor manufacturers, tool development companies and instrument manufacturers have formed NEXUS 5001 Forum in 1998, which is a standard for embedded control applications and define embedded processor debug interface standards. Joint organization, the previous name is the Global Embedded Processor Debug Interface Standard Consortium (Global Embedded Processor Debug Interface Standard Association). Nexus now has 24 member units, including found members Motorola, Infineon Technologies, Hitachi, ETAS, and HP. The organization first processes the commissioning required for automotive power applications, and now has developed a general interface for commissioning data communication, wireless systems, and other real-time embedded applications. Reference MPC860 PowerQuicc User's Manual Motorola http://www.vas-gmbh.de/software/mpcbdm/ http://www.metrowerks.com/tools/documentation/embedded / zeofbdm http://www.redhat.com/ Support / wpapers / cygnus_heinsenberg / trace.html http://www.ednmag.com/reg/2000/05112000/10tt.htm
Author brief introduction to bear training, worked in the Chinese Academy of Sciences to calculate the embedded system software group. Mainly engaged in the development of an emulator, debugger, and integrated development environment for embedded operating systems. You can contact him with email jxiong@ict.ac.cn.
