1*9712c20fSFrederick Mayle# Introduction 2*9712c20fSFrederick Mayle 3*9712c20fSFrederick MayleLinux implements its userland-to-kernel transition using a special library 4*9712c20fSFrederick Maylecalled linux-gate.so that is mapped by the kernel into every process. For more 5*9712c20fSFrederick Mayleinformation, see 6*9712c20fSFrederick Mayle 7*9712c20fSFrederick Maylehttp://www.trilithium.com/johan/2005/08/linux-gate/ 8*9712c20fSFrederick Mayle 9*9712c20fSFrederick MayleIn a nutshell, the problem is that the system call gate function, 10*9712c20fSFrederick Maylekernel\_vsyscall does not use EBP to point to the frame pointer. 11*9712c20fSFrederick Mayle 12*9712c20fSFrederick MayleHowever, the Breakpad processor supports special frames like this via STACK 13*9712c20fSFrederick Maylelines in the symbol file. If you look in src/client/linux/data you will see 14*9712c20fSFrederick Maylesymbol files for linux-gate.so for both Intel & AMD(the implementation of 15*9712c20fSFrederick Maylekernel\_vsyscall changes depending on the CPU manufacturer). When processing 16*9712c20fSFrederick Mayleminidumps from Linux 2.6, having these symbol files is necessary for walking the 17*9712c20fSFrederick Maylestack for crashes that happen while a thread is in a system call. 18*9712c20fSFrederick Mayle 19*9712c20fSFrederick MayleIf you're just interested in processing minidumps, those two symbol files should 20*9712c20fSFrederick Maylebe all you need! 21*9712c20fSFrederick Mayle 22*9712c20fSFrederick Mayle# Details 23*9712c20fSFrederick Mayle 24*9712c20fSFrederick MayleThe particular details of understanding the linux-gate.so symbol files can be 25*9712c20fSFrederick Maylefound by reading about STACK lines inside 26*9712c20fSFrederick Maylesrc/common/windows/pdb\_source\_line\_writer.cc, and the above link. To 27*9712c20fSFrederick Maylesummarize briefly, we just have to inform the processor how to get to the 28*9712c20fSFrederick Mayleprevious frame when the EIP is inside kernel\_vsyscall, and we do that by 29*9712c20fSFrederick Mayletelling the processor how many bytes kernel\_vsyscall has pushed onto the stack 30*9712c20fSFrederick Maylein it's prologue. For example, one of the symbol files looks somewhat like the 31*9712c20fSFrederick Maylefollowing: 32*9712c20fSFrederick Mayle 33*9712c20fSFrederick MayleMODULE Linux x86 random\_debug\_id linux-gate.so PUBLIC 400 0 kernel\_vsyscall 34*9712c20fSFrederick MayleSTACK WIN 4 100 1 1 0 0 0 0 0 1 35*9712c20fSFrederick Mayle 36*9712c20fSFrederick MayleThe PUBLIC line indicates that kernel\_vsyscall is at offset 400 (in bytes) from 37*9712c20fSFrederick Maylethe beginning of linux-gate.so. The STACK line indicates the size of the 38*9712c20fSFrederick Maylefunction(100), how many bytes it pushes(1), and how many bytes it pops(1). The 39*9712c20fSFrederick Maylelast 1 indicates that EBP is pushed onto the stack before being used by the 40*9712c20fSFrederick Maylefunction. 41*9712c20fSFrederick Mayle 42*9712c20fSFrederick Mayle# Warnings 43*9712c20fSFrederick Mayle 44*9712c20fSFrederick MayleThese functions might change significantly depending on kernel version. In my 45*9712c20fSFrederick Mayleopinion, the actual function stack information is unlikely to change frequently, 46*9712c20fSFrederick Maylebut the Linux kernel might change the address of kernel\_vsyscall w.r.t the 47*9712c20fSFrederick Maylebeginning of linux-gate.so, which would cause these symbol files to be invalid. 48