Ftrace debugging interface for Linux Kernel

In order to grasp how a custom kernel function is executed, some debugging methods are required. In fact, a tracing method is required, which is not very complex in theory, however, there are too many debugging interfaces in the Linux kernel, and it cannot be found easily until ftrace is encountered. It simply uses the file system as the interface and does not need to install any user State.ProgramIt has nothing to do with the messy release version. This is exactly what I want. It is great compared to the complicated pre-setup and debugging methods such as systemtap. Because I hate to spend a lot of time doing front jobs to do something theoretically simple.
The advantages of using a file system as an interface are needless to say. It can map any complicated operations to simple operations such as reading, writing, controlling, opening, and closing, another advantage of ftrace is its dynamic binary correction technology. In fact, kprobe also uses the binary correction technology, but it is very hard, and ftrace uses the built-in mcount mechanism of GCC to reload the mcount function to complete the statistics of arbitrary function calls.

The mcount mechanism is a feature of GCC. some information about this function is recorded during any function call. For example, the following program:

Mcount. C:

 
# Include <stdio. h> void mcount () {printf ("@ \ n ");}
 

Gcc-C mcount. c

Main. C:

# Include <stdlib. h> # include <stdio. h> extern void mcount (void); void B (int I) {printf ("B: % d \ n", I);} int A (int I) {B (I); return 3 ;}int main () {int I = 3; int K = a (I); Return K ;}
 

Gcc-C main. C-PG
GCC mcount. O main. O-o Test

Run test, and you will find that @ is printed for each function call. This indicates that the mcount is reloaded successfully. If you can make mcount into a stub function that only executes ret, or even call mcount executes the stub of Nop together, it is equivalent to not using this mcount function. If you enable ftrace at a certain time, then replace the above stub with the real trace function. can we enable or disable the trace function dynamically? This is exactly what Linux kernel does. To do this, the stub function should be flexible enough. For example, the above mcount. c/Main. C is a flexible but not absolutely flexible design framework as follows:

 
Char code [] = {0xc3, 0x90, 0x90 ...} // 0xc3 is direct retvoid mcount () {int (* PF) (void); pF = & code [0]; PF ();}
 

If the trace function is enabled, replace the Code with the operation code of call real_func. Instead, real_func can use register instead of a fixed function, then we can replace the trace function as needed to implement any trace style. The Linux kernel practices are much more flexible than me. Through the callback func mechanism, it can even draw a function call diagram, which is very powerful. By the way, the implementation of the trace callback function utilizes the Kernel Function Location table generated during kernel compilation. Its entries are the ing between the function name and location, the trace callback function finds the function name based on the current address.
My above framework is just a framework. If you really compile and run it, you will find a disgusting segment fault. This is because most of the kernels currently implement data section unexecutable, text Section cannot be written. If you want to do so, general protection exceptions may occur. Therefore, you need to do a lot of work on link scripts. This laborious thing will not be said, and it is tears to say more!

The core of ftrace is to use the mcount mechanism and the file system mechanism. It is very simple to use. You only need to mount debugfs and you can debug it at will:

Mount-T debugfs/debug

Then go to the/debug/tracing directory and check available_tracers to see what trace functions are supported by your current kernel. If there is a function, your kernel supports the function tracking function, ftrace supports filtering, such as filtering by kernel function and by process. The following is a trace result segment for a Long Ping:

0) | sys_socketcall (){
0) | copy_from_user (){
0) | _ copy_from_user (){
0) 0.137 us | _ cond_resched ();
0) 0.457 us |}
0) 0.806 us |}
0) 0.130 us | audit_socketcall ();
0) | sys_recvmsg (){
0) | sockfd_lookup_light (){
0) 0.228 us | fget_light ();
0) 0.558 us |}
0) | _ sys_recvmsg (){
0) | _ copy_from_user (){
0) 0.130 us | _ cond_resched ();
0) 0.405 us |}
0) | verify_iovec (){
0) | _ copy_from_user (){
0) 0.129 us | _ cond_resched ();
0) 0.429 us |}
0) 0.736 us |}
0) | sock_recvmsg (){
0) | security_socket_recvmsg (){
0) | apparmor_socket_recvmsg (){
0) 0.179 us | aa_revalidate_sk ();
0) 0.482 us |}
0) 0.945 us |}
0) 0.210 us | sock_update_classid ();
0) | inet_recvmsg (){

Not only can the function call diagram be drawn, but its timing statistics are also of reference significance for performance analysis.

Ftrace is very powerful. You do not need to configure the system or install additional software. You can directly use the file system interface. I like this mechanism very much, because I hate the need for additional configuration mechanisms, which has prompted many people to go wrong. While they show off the command-making skills, it puts a lot of pressure on others. In fact, insiders know that most of their commands are used to build the trace environment, rather than solving real problems. Therefore, such commands also include apt-get, if you don't understand it, you will think it is very fierce!