Lab work: Make GDB trace analyze a system call kernel function

Lab Job: Make GDB Trace Parse a system call kernel function (I'm using Getuid)

20135313 Wu Ziyi. Beijing Institute of Electronic Technology

"first part" according to the video demonstration steps, first part, the steps are as follows

① Updating the menu code to the latest version

② adding C functions and assembly functions to the Code

③ add Makeconfig to the main function

④make Rootfs

⑤ can see the addition of the commands we added earlier in QEMU:

⑥ execute the new command separately

"Part Two" GDB Trace analysis of a system call kernel function

① into GDB debug

② set breakpoints, continue execution:

The ③ corresponds to the result:

④ View the functions I have chosen for system calls:

⑤ set breakpoints at Sys_getuid16:

⑥ found that executing the command Getuid did not stop.

⑦ instead stopped at the execution of Getuid_asm.

⑧ directly ends a number of single-step executions, and then continues to step down, discovering that a process dispatch function has returned, returning the value of one of the current process tasks in the process schedule.

⑨ set breakpoints at System_call. The getuid_asm that stopped just now returns the value when the discovery can be stopped and the execution continues.

Note: The video mentions: System_call is not a normal function, the analysis is more difficult, the teacher did not ask for homework, also did not decorate for the job. So the deadline is here.

"Part Three" System_call to Iret process flowchart

"Part Four" problems encountered

In the video: When you enter time in Qemu, the breakpoint is set to stop. In my operation, the input getuid did not stop, but stopped at Getuid_asm. This does not know why, repeated to do several times still did not solve. Even starting over and doing it again is the same.

Resolved issues:

1. The catalogue is very IMPORTANT!!! Because a lot of commands disorderly use the path, resulting in the back of the time only to find the clone location error, the compilation location can not find files and so on! This problem is difficult to find without LS or to go back to watch the video! So it's important to be careful!!!!! Target Remote connection Timeout is also a big reason for the wrong directory! And GDB began to the wrong position, did not enter into the linuxkernel inside.

"Part Five" blog content details (Analysis of the system_call corresponding to the assembly code of the work process, the system call back to Iret before the process scheduling time)

Summary of knowledge points please go link: point me!

Summary of "Part VI"

"System invocation process and extension to interrupt processing"

The specific system call is bound to the system call number and is then documented in a system call table, each time the system call is made through such a binding relationship, the system call number is used to find the system call table and then find the location of the corresponding system call.

Similarly, the interrupt processing process is the same, it also through the interrupt vector number as an index to look up the table, and then execute the corresponding specific interrupt handler to deal with the interruption.

In short, "Two & two sheets".

"part Seventh" Appendix

Wu Ziyi

Study No.: 20135313

Original works reproduced please indicate the source

"Linux kernel Analysis" MOOC course http://mooc.study.163.com/course/USTC-1000029000

Lab work: Make GDB trace analyze a system call kernel function