Linux Kernel GDB tracepoint module

(KGTP)

Update in 2014-07-22

关于本文

http://teawater.github.io/kgtp/kgtpcn.html 是HTML格式的本文最后版本。

https://raw.github.com/teawater/kgtp/master/kgtpcn.pdf 是PDF格式的本文最后版本。

https://raw.github.com/teawater/kgtp/release/kgtpcn.pdf 是PDF格式的本文最后发布版本。

什么是KGTP

KGTP是一个能在产品系统上实时分析Linux内核和应用程序(包括Android)问题的全面动态跟踪器。

使用KGTP 不需要 在Linux内核上打PATCH或者重新编译，只要编译KGTP模块并insmod就可以。

其让Linux内核提供一个远程GDB调试接口，于是在本地或者远程的主机上的GDB可以在不需要停止内核的情况下用GDB tracepoint和其他一些功能 调试 和 跟踪 Linux内核和应用程序。

即使板子上没有GDB而且其没有可用的远程接口，KGTP也可以用离线调试的功能调试内核（见/sys/kernel/debug/gtpframe 和 离线调试）。

http://www.youtube.com/watch?v=7nfGAbNsEZY 或者 http://www.tudou.com/programs/view/fPu_koiKo38/ 是介绍KGTP的英文视频。

http://www.infoq.com/cn/presentations/gdb-sharp-knife-kgtp-linux-kernel 是介绍KGTP的中文视频。

KGTP支持 X86-32 ， X86-64 ， MIPS 和 ARM 。

KGTP支持大部分版本的Linux内核 (从2.6.18 到最新版)。

请到 UPDATE 去看KGTP的更新信息。

快速配置和启动KGTP

#kgtp.py将在本机上自动配置和启动KGTP和GDB。

#第一次使用这个脚本需要等一段时间因为有一些包需要下载。

wget https://raw.githubusercontent.com/teawater/kgtp/master/kgtp.py

sudo python kgtp.py

#访问内核的内存。

(gdb) p jiffies_64

$2 = 5081634360

#在函数vfs_read上设置trace点并收集这个函数的backtrace信息。

(gdb) trace vfs_read

Tracepoint 1 at 0xffffffff811b8c70: file fs/read_write.c, line 382.

(gdb) actions

Enter actions for tracepoint 1, one per line.

End with a line saying just "end".

>collect $bt

>end

(gdb) tstart

(gdb) tstop

(gdb) tfind

Found trace frame 0, tracepoint 1

#0 vfs_read (file=file@entry=0xffff88022017b000,

buf=buf@entry=0x7fff0fdd80f0 <Address 0x7fff0fdd80f0 out of bounds>,

count=count@entry=16, pos=pos@entry=0xffff8800626aff50) at fs/read_write.c:382

382 {

(gdb) bt

#0 vfs_read (file=file@entry=0xffff88022017b000,

buf=buf@entry=0x7fff0fdd80f0 <Address 0x7fff0fdd80f0 out of bounds>,

count=count@entry=16, pos=pos@entry=0xffff8800626aff50) at fs/read_write.c:382

#1 0xffffffff811b9819 in SYSC_read (count=16,

buf=0x7fff0fdd80f0 <Address 0x7fff0fdd80f0 out of bounds>, fd=<optimized out>)

at fs/read_write.c:506

如果要在远程主机或者和Android一起使用KGTP，请阅读附录A 使用KGTP前的准备工作和附录B 如何让GDB连接KGTP。

需要帮助或者汇报问题

请把问题发到https://github.com/teawater/kgtp/issues。

或者写信到mailto:teawater@gmail.com?Subject=汇报一个KGTP的问题。

或者汇报到QQ群317654748。

KGTP小组将尽全力帮助你。

请到 https://code.google.com/p/kgtp/issues/list 访问旧问题列表。

GDB调试普通程序和KGTP的区别表

这个表是给在使用过GDB调试程序的人准备的，他可以帮助你理解和记住KGTP的功能。

如何使用GDB控制KGTP跟踪和调试Linux内核

在普通模式直接访问当前值

在GDB连到KGTP上以后，如果没有用GDB命令"tfind"选择一条trace帧缓存里面的条目，GDB就处于 普通模式。于是你可以直接访问内存(Linux内核或者用户程序)的值和trace状态变量的值。

如果你选择了一个trace帧条目，可以用GDB命令"tfind -1"返回到普通模式。请到在普通模式直接访问当前值取得GDB命令"tfind"的更多信息。

Linux内核的内存

例如你可以用下面的命令访问"jiffies_64"：

(gdb) p jiffies_64

或者你可以用下面的命令访问"static LIST_HEAD(modules)"的第一条记录：

(gdb) p *((struct module *)((char *)modules->next - ((size_t) &(((struct module *)0)->list))))

或者你可以访问"DEFINE_PER_CPU(struct device *, mce_device);"CPU0的数据：

p *(struct device *)(__per_cpu_offset[0]+(uint64_t)(&mce_device))

如果想在用一个GDB命令显示多个变量，请使用下面的例子：

(gdb) printf "%4d %4d %4d %4d %4d %4d %18d %lu\n", this_rq->cpu, this_rq->nr_running, this_rq->nr_uninterruptible, nr_active, calc_load_tasks->counter, this_rq->calc_load_active, delta, this_rq->calc_load_update

2 1 0 0 0 0 673538312 717077240

trace状态变量

你可以使用和访问内存一样的命令访问TSV。 请到 如何使用trace状态变量 取得更多TSV的信息。

GDB tracepoint

tracepoint就是GDB定义一些地址和一些动作。在tracepoint启动之后，当Linux内核执行到那些地址的时候，KGTP将执行这些动作(它们中的有些会收集数据并存入tracepoint帧缓冲)并把它们发给调试目标(KGTP)。而后，Linux内核将继续执行。

KGTP提供了一些接口可以让GDB或者其他程序取出tracepoint帧缓冲的数据做分析。

关于这些接口，文档前面已经介绍了"/sys/kernel/debug/gtp"，将在后面介绍"/sys/kernel/debug/gtpframe" 和 "/sys/kernel/debug/gtpframe_pipe"。

GDB tracepoint文档在 http://sourceware.org/gdb/current/onlinedocs/gdb/Tracepoints.html。

设置tracepint

trace命令非常类似break命令，它的参数可以是文件行，函数名或者一个地址。trace将定义一个或者多个地址定义一个tracepoint，KGTP将在这个点做一些动作。

这是一些使用trace命令的例子：

(gdb) trace foo.c:121 // 一个文件和行号

(gdb) trace +2 // 2行以后

(gdb) trace my_function // 函数的第一行

(gdb) trace *my_function // 函数的第一个地址

(gdb) trace *0x2117c4 // 一个地址

这个函数确实存在但是设置tracepoint到上面会失败如何处理?

GCC为了提高程序执行效率会inline一些static函数。因为目标文件没有inline函数的符号，所以你不能设置tracepoint在函数名上。

你可以用"trace 文件:行号"在其上设置断点。

如何设置条件tracepoint

http://sourceware.org/gdb/current/onlinedocs/gdb/Tracepoint-Conditions.html

和breakpoint一样，我们可以设置tracepoint的触发条件。而且因为条件检查是在KGTP执行的，所以速度比breakpoint的条件检查快很多。

例如：

(gdb) trace handle_irq if (irq == 47)

tracepoint 1的动作将只在irq是47的时候才被执行。

你还可以用GDB命令"condition"设置tracepoint的触发条件。GDB命令"condition N COND"将设置tracepoint N只有条件COND为真的时候执行。

例如：

(gdb) trace handle_irq

(gdb) condition 1 (irq == 47)

GDB命令"info tracepoint"将显示tracepoint的ID。

$bpnum的值是最后一个GDB tracepoint的ID，所以你可以不取得tracepoint的ID就用condition来设置最后设置的tracepoint的条件，例如：

(gdb) trace handle_irq

(gdb) condition $bpnum (irq == 47)

如何处理错误 "Unsupported operator (null) (52) in expression."

如果你使用关于字符串的条件tracepoint，你在调用"tstart"的时候可能得到这个出错信息。

你可以转化char为int来处理这个问题，例如：

(gdb) p/x 'A'

$4 = 0x41

(gdb) condition 1 (buf[0] == 0x41)

actions [num]

这个命令将设置一组action当tracepoint num触发的时候执行。如果没有设置num则将设置action到最近创建的tracepoint上(因此你可以定义一个tracepoint然后直接输入actions而不需要参数)。然后就要在后面输入action，最后以end为结束。到目前为止，支持的action有collect，teval和while-stepping。

collect expr1, expr2, ...

当tracepoint触发的时候，收集表达式的值。这个命令可接受用逗号分割的一组列表，这些列表除了可以是全局，局部或者本地变量，还可以是下面的这些参数：

$regs 收集全部寄存器。

$args 收集函数参数。

$locals 收集全部局部变量。

请 注意 collect 一个指针(collect ptr)将只能collect这个指针的地址. 在指针前面增加一个 * 将会让action collect指针指向的数据(collect *ptr)。

teval expr1, expr2, ...

当tracepoint触发的时候，执行指定的表达式。这个命令可接受用逗号分割的一组列表。表达式的结果将被删除，所以最主要的作用是把值设置到trace状态变量中 (see 普通trace状态变量)，而不用像collect一样把这些值存到trace帧中。

while-stepping n

请到 使用while-stepping让Linux内核做单步 去看如何使用它。

启动和停止 tracepoint

tracepoint只有在用下面的GDB命令启动后才可以执行action：

(gdb) tstart

它可以用下面的命令停止：

(gdb) tstop

Enable 和 disable tracepoint

和breakpoint一样，tracepoint可以使用GDB命令 "enable" 和 "disable"。但是请 注意 它们只在tracepoint停止的时候有效。

用tfind选择trace帧缓存里面的条目

tracepoint停止的时候，GDB命令"tfind"可以用来选择trace帧缓存里面的条目。

当GDB在"tfind"模式的时候，其只能显示用collection命令收集的的存在于这个条目中的数据。所以如果打印没有collect的数据例如函数的参数的时候，GDB将输出一些错误信息。这不是bug，不用担心。

如果想选择下一个条目，可以再次使用命令"tfind"。还可以用"tfind 条目ID"去选择某个条目。

要回到普通模式(在普通模式直接访问当前值)，请使用GDB命令"tfind -1"。 请到 http://sourceware.org/gdb/current/onlinedocs/gdb/tfind.html 取得它的详细信息。

如何处理错误 "No such file or directory." 或者 "没有那个文件或目录."

当GDB不能找到Linux内核源码的时候，其就会显示这个错误信息。 例如：

(gdb) tfind

Found trace frame 0, tracepoint 1

#0 vfs_read (file=0xffff8801b6c3a500, buf=0x3f588b8 <Address 0x3f588b8 out of bounds>, count=8192,

pos=0xffff8801eee49f48) at /build/buildd/linux-3.2.0/fs/read_write.c:365

365 /build/buildd/linux-3.2.0/fs/read_write.c: 没有那个文件或目录.

你可以用GDB命令 "set substitute-path" 处理它。前面这个例子Linux内核源码在"/build/buildd/test/linux-3.2.0/"但是vmlinux让GDB在"/build/buildd/linux-3.2.0/"找内核远啊，你可以处理他们：

(gdb) set substitute-path /build/buildd/linux-3.2.0/ /build/buildd/test/linux-3.2.0/

(gdb) tfind

Found trace frame 1, tracepoint 1

#0 vfs_read (file=0xffff8801c36e6400, buf=0x7fff51a8f110 <Address 0x7fff51a8f110 out of bounds>, count=16,

pos=0xffff8801761dff48) at /build/buildd/linux-3.2.0/fs/read_write.c:365

365 {

GDB还提供其他的命令处理源码问题，请到http://sourceware.org/gdb/current/onlinedocs/gdb/Source-Path.html取得他们的介绍。

保存trace帧信息到一个文件中

/sys/kernel/debug/gtpframe是一个当KGTP停止时的tfind格式（GDB可以读取它）的接口。

请 注意 有些"cp"不能很好的处理这个问题，可以用"cat /sys/kernel/debug/gtpframe > ./gtpframe"拷贝它。

你可以在需要的时候打开文件gtpframe:

(gdb) target tfile ./gtpframe

Tracepoint 1 at 0xffffffff8114f3dc: file /home/teawater/kernel/linux-2.6/fs/readdir.c, line 24.

Created tracepoint 1 for target's tracepoint 1 at 0xffffffff8114f3c0.

(gdb) tfind

Found trace frame 0, tracepoint 1

#0 vfs_readdir (file=0xffff880036e8f300, filler=0xffffffff8114f240 <filldir>, buf=0xffff880001e5bf38)

at /home/teawater/kernel/linux-2.6/fs/readdir.c:24

24 {

显示和存储tracepoint

你可以用GDB命令"info tracepoints"显示所有的tracepoint。

你可以用GDB命令"save tracepoints filename"保存所有的设置tracepoint的命令到文件filename里。于是你可以在之后用GDB命令"source filename"设置重新这些tracepoint。

删除tracepoint

GDB命令"delete id"将删除tracepoint id。如果"delete"没有参数，则删除所有tracepoint。

用tracepoint从内核中某点取得寄存器信息

下面是记录内核调用函数"vfs_readdir"时的寄存器信息的例子：

(gdb) target remote /sys/kernel/debug/gtp

(gdb) trace vfs_readdir

Tracepoint 1 at 0xc01a1ac0: file

/home/teawater/kernel/linux-2.6/fs/readdir.c, line 23.

(gdb) actions

Enter actions for tracepoint 1, one per line.

End with a line saying just "end".

>collect $reg

>end

(gdb) tstart

(gdb) shell ls

(gdb) tstop

(gdb) tfind

Found trace frame 0, tracepoint 1

#0 0xc01a1ac1 in vfs_readdir (file=0xc5528d00, filler=0xc01a1900 <filldir64>,

buf=0xc0d09f90) at /home/teawater/kernel/linux-2.6/fs/readdir.c:23

23 /home/teawater/kernel/linux-2.6/fs/readdir.c: No such file or directory.

in /home/teawater/kernel/linux-2.6/fs/readdir.c

(gdb) info reg

eax 0xc5528d00 -984445696

ecx 0xc0d09f90 -1060069488

edx 0xc01a1900 -1072031488

ebx 0xfffffff7 -9

esp 0xc0d09f8c 0xc0d09f8c

ebp 0x0 0x0

esi 0x8061480 134616192

edi 0xc5528d00 -984445696

eip 0xc01a1ac1 0xc01a1ac1 <vfs_readdir+1>

eflags 0x286 [ PF SF IF ]

cs 0x60 96

ss 0x8061480 134616192

ds 0x7b 123

es 0x7b 123

fs 0x0 0

gs 0x0 0

(gdb) tfind

Found trace frame 1, tracepoint 1

0xc01a1ac1 23 in /home/teawater/kernel/linux-2.6/fs/readdir.c

(gdb) info reg

eax 0xc5528d00 -984445696

ecx 0xc0d09f90 -1060069488

edx 0xc01a1900 -1072031488

ebx 0xfffffff7 -9

esp 0xc0d09f8c 0xc0d09f8c

ebp 0x0 0x0

esi 0x8061480 134616192

edi 0xc5528d00 -984445696

eip 0xc01a1ac1 0xc01a1ac1 <vfs_readdir+1>

eflags 0x286 [ PF SF IF ]

cs 0x60 96

ss 0x8061480 134616192

ds 0x7b 123

es 0x7b 123

fs 0x0 0

gs 0x0 0

用tracepoint从内核中某点取得变量的值

下面是记录内核调用函数"vfs_readdir"时"jiffies_64"的值的例子：

(gdb) target remote /sys/kernel/debug/gtp

(gdb) trace vfs_readdir

Tracepoint 1 at 0xc01ed740: file /home/teawater/kernel/linux-2.6/fs/readdir.c, line 24.

(gdb) actions

Enter actions for tracepoint 1, one per line.

End with a line saying just "end".

>collect jiffies_64

>collect file->f_path.dentry->d_iname

>end

(gdb) tstart

(gdb) shell ls

arch drivers include kernel mm Module.symvers security System.map virt

block firmware init lib modules.builtin net sound t vmlinux

crypto fs ipc Makefile modules.order scripts source usr vmlinux.o

(gdb) tstop

(gdb) tfind

Found trace frame 0, tracepoint 1

#0 0xc01ed741 in vfs_readdir (file=0xf4063000, filler=0xc01ed580 <filldir64>, buf=0xd6dfdf90)

at /home/teawater/kernel/linux-2.6/fs/readdir.c:24

24 {

(gdb) p jiffies_64

$1 = 4297248706

(gdb) p file->f_path.dentry->d_iname

$1 = "b26", '\000' <repeats 28 times>

显示当前这一条trace缓存里存储的所有信息

在用"tfind"选择好一个条目后，你可以用"tdump"。

(gdb) tdump

Data collected at tracepoint 1, trace frame 0:

$cr = void

file->f_path.dentry->d_iname = "gtp\000.google.chrome.g05ZYO\000\235\337\000\000\000\000\200\067k\364\200\067", <incomplete sequence \364>

jiffies_64 = 4319751455

取得 tracepoint 的状态

请用GDB命令"tstatus"。

设置trace缓存为循环缓存

http://sourceware.org/gdb/current/onlinedocs/gdb/Starting-and-Stopping-Trace-Experiments.html

帧缓存默认情况下不是循环缓存。当缓存满了的时候，tracepoint将停止。

下面的命令将设置trace缓存为循环缓存，当缓存满了的时候，其将自动删除最早的数据并继续trace。

(gdb) set circular-trace-buffer on

GDB断开的时候不要停止tracepoint

http://sourceware.org/gdb/current/onlinedocs/gdb/Starting-and-Stopping-Trace-Experiments.html

默认情况下，当GDB断开KGTP的时候将自动停止tracepoint并删除trace帧。

下面的命令将打开KGTP disconnect-trace。在设置之后，当GDB断开KGTP的时候，KGTP将不停止tracepoint。GDB重新连到KGTP的时候，其可以继续控制KGTP。

(gdb) set disconnected-tracing on

kprobes-optimization和tracepoint的执行速度

因为tracepoint是和Linux内核一起执行，所以它的速度将影响到系统执行的速度。

KGTP tracepoint是基于Linux内核kprobe。因为普通kprobe是基于断点指令，所以它的速度不是很快。

但是如果你的arch是X86_64 或者 X86_32 而且内核配置没有打开"Preemptible Kernel" (PREEMPT)，kprobe的速度将被kprobes-optimization (CONFIG_OPTPROBES)提高很多。

可以用下面的命令来确认：

sysctl -A | grep kprobe

debug.kprobes-optimization = 1

这个的意思就是你的系统支持kprobes-optimization。

请 注意 一些KGTP的功能会导致tracepoint只能使用普通kprobe即使系统支持kprobes-optimization。文档将在介绍这些功能的时候增加提醒，如果你很介意tracepoint的速度就请避免使用这些功能。

如何使用trace状态变量

http://sourceware.org/gdb/current/onlinedocs/gdb/Trace-State-Variables.html

trace状态变量简称TSV。

TSV可以在tracepoint action和condition中被访问，并且可以直接被GDB命令访问。

请 注意 GDB 7.2.1和更晚的版本直接访问trace状态变量，比他们老的GDB只能通过命令"info tvariables"取得trace状态变量的值。

普通trace状态变量

定义trace状态变量$c.

(gdb) tvariable $c

trace状态变量 $c 被创建并初始化0。 下面的action将使用$c记录内核里发生了多少次IRQ。

(gdb) target remote /sys/kernel/debug/gtp

(gdb) trace handle_irq

(gdb) actions

Enter actions for tracepoint 3, one per line.

End with a line saying just "end".

>collect $c #Save current value of $c to the trace frame buffer.

>teval $c=$c+1 #Increase the $c.

>end

你还可以将某个变量的值传到状态变量里，但是别忘记转化这个值为"uint64_t"。

>teval $c=(uint64_t)a

你可以取得$c的值当trace在运行或者停止的时候。

(gdb) tstart

(gdb) info tvariables

$c 0 31554

(gdb) p $c

$5 = 33652

(gdb) tstop

(gdb) p $c

$9 = 105559

当使用tfind的时候，你可以分析trace frame buffer。如果trace状态变量被收集了，你可以把它取出来。

(gdb) tstop

(gdb) tfind

(gdb) info tvariables

$c 0 0

(gdb) p $c

$6 = 0

(gdb) tfind 100

(gdb) p $c

$7 = 100

需要的时候，访问trace状态变量的tracepoint action将自动加锁，所以其可以很好的处理trace状态变量的竞态条件问题。

下面这个例子即使在一个多CPU的环境也可以正常使用。

>teval $c=$c+1

Per_cpu trace状态变量

Per_cpu trace状态变量是一种特殊的trace状态变量。 当一个tracepoint action访问到其的时候，其将自动访问这个CPU的Per_cpu trace状态变量。

它有两个优点：

1. 访问Per_cpu trace状态变量的tracepoint actions不存在竞态条件问题，所以其不需要对trace状态变量加锁。所以其在多核的机器上速度更快。

2. 写针对记录某个CPU的tracepoint actions比普通trace状态变量更容易。

如何定义

Per_cpu trace状态变量有两种类型：

本地CPU变量

"per_cpu_"+string

或者

"p_"+string

例如：

(gdb) tvariable $p_count

在tracepoint action中访问这个trace状态变量的时候，其将返回这个变量在这个action运行的CPU上的值。

CPU id变量

"per_cpu_"+string+CPU_id

或者

"p_"+string+CPU_id

例如：

(gdb) tvariable $p_count0

(gdb) tvariable $p_count1

(gdb) tvariable $p_count2

(gdb) tvariable $p_count3

在tracepoint action或者GDB命令行中访问这个变量的时候，其将返回这个变量在CPU CPI_id 上的值。

下面这个例子可以自动这个这台主机上的每个CPU定义CPU id变量。(请 注意 用这些命令之前需要让GDB连上KGTP。)

(gdb) set $tmp=0

(gdb) while $tmp<$cpu_number

>eval "tvariable $p_count%d",$tmp

>set $tmp=$tmp+1

>end

例子1

这个例子定义了一个记录每个CPU调用多少次vfs_read的tracepoint。

tvariable $p_count

set $tmp=0

while $tmp<$cpu_number

eval "tvariable $p_count%d",$tmp

set $tmp=$tmp+1

end

trace vfs_read

actions

teval $p_count=$p_count+1

end

于是你可以在"tstart"后显示每个CPU调用了多少次vfs_read：

(gdb) p $p_count0

$3 = 44802

(gdb) p $p_count1

$4 = 55272

(gdb) p $p_count2

$5 = 102085

(gdb) p $p_count3

例子2

这个例子记录了每个CPU上关闭IRQ时间最长的函数的stack dump。

set pagination off

tvariable $bt=1024

tvariable $p_count

tvariable $p_cc

set $tmp=0

while $tmp<$cpu_number

eval "tvariable $p_cc%d",$tmp

set $tmp=$tmp+1

end

tvariable $ignore_error=1

trace arch_local_irq_disable

actions

teval $p_count=$clock

end

trace arch_local_irq_enable if ($p_count && $p_cc < $clock - $p_count)

actions

teval $p_cc = $clock - $p_count

collect $bt

collect $p_cc

teval $p_count=0

end

enable

set pagination on

特殊trace状态变量 $current_task，$current_task_pid，$current_thread_info，$cpu_id，$dump_stack，$printk_level，$printk_format，$printk_tmp，$clock，$hardirq_count，$softirq_count 和 $irq_count

KGTP特殊trace状态变量$current_task，$current_thread_info，$cpu_id 和 $clock可以很容易的访问各种特殊的值，当你用GDB连到KGTP后就可以访问到他们。 你可以在tracepoint条件和actions里使用他们。

在tracepoint条件和actions里访问$current_task可以取得get_current()的返回值。

在tracepoint条件和actions里访问$current_task_pid可以取得get_current()->pid的值。

在tracepoint条件和actions里访问$current_thread_info可以取得current_thread_info()的返回值。

在tracepoint条件和actions里访问$cpu_id可以取得smp_processor_id()的返回值。

在tracepoint条件和actions里访问$clock可以取得local_clock()的返回值，也就是取得纳秒为单位的时间戳。

$rdtsc只在体系结构是X86或者X86_64的时候访问的到，任何时候访问它可以取得用指令RDTSC取得的TSC的值。

在tracepoint条件和actions里访问$hardirq_count可以取得hardirq_count()的返回值。

在tracepoint条件和actions里访问$softirq_count可以取得softirq_count()的返回值。

在tracepoint条件和actions里访问$irq_count可以取得irq_count()的返回值。

KGTP还有一些特殊trace状态变量$dump_stack，$printk_level，$printk_format 和 $printk_tmp。他们可以用来直接显示值，请看如何让tracepoint直接输出信息。

下面是一个用$c记录进程16663调用多少次vfs_read并收集thread_info结构的例子：

(gdb) target remote /sys/kernel/debug/gtp

(gdb) trace vfs_read if (((struct task_struct *)$current_task)->pid == 16663)

(gdb) tvariable $c

(gdb) actions

Enter actions for tracepoint 4, one per line.

End with a line saying just "end".

>teval $c=$c+1

>collect (*(struct thread_info *)$current_thread_info)

>end

(gdb) tstart

(gdb) info tvariables

Name Initial Current

$c 0 184

$current_task 0 <unknown>

$current_thread_info 0 <unknown>

$cpu_id 0 <unknown>

(gdb) tstop

(gdb) tfind

(gdb) p *(struct thread_info *)$current_thread_info

$10 = {task = 0xf0ac6580, exec_domain = 0xc07b1400, flags = 0, status = 0, cpu = 1, preempt_count = 2, addr_limit = {

seg = 4294967295}, restart_block = {fn = 0xc0159fb0 <do_no_restart_syscall>, {{arg0 = 138300720, arg1 = 11,

arg2 = 1, arg3 = 78}, futex = {uaddr = 0x83e4d30, val = 11, flags = 1, bitset = 78, time = 977063750,

uaddr2 = 0x0}, nanosleep = {index = 138300720, rmtp = 0xb, expires = 335007449089}, poll = {

ufds = 0x83e4d30, nfds = 11, has_timeout = 1, tv_sec = 78, tv_nsec = 977063750}}},

sysenter_return = 0xb77ce424, previous_esp = 0, supervisor_stack = 0xef340044 "", uaccess_err = 0}

这是一个记录每个CPU调用了多少次sys_read()的例子。

(gdb) tvariable $c0

(gdb) tvariable $c1

(gdb) trace sys_read

(gdb) condition $bpnum ($cpu_id == 0)

(gdb) actions

>teval $c0=$c0+1

>end

(gdb) trace sys_read

(gdb) condition $bpnum ($cpu_id == 1)

(gdb) actions

>teval $c1=$c1+1

>end

(gdb) info tvariables

Name Initial Current

$current_task 0 <unknown>

$cpu_id 0 <unknown>

$c0 0 3255

$c1 0 1904

sys_read() 在CPU0上被执行了3255次，CPU1上执行了1904次。请 注意 这个例子只是为了显示如何使用$cpu_id，实际上用per_cpu trace状态变量写更好。

特殊trace状态变量 $self_trace

$self_trace和前面介绍的特殊trace状态变量不同，它是用来控制tracepoint的行为的。

默认情况下，tracepoint被触发后，如果current_task是KGTP自己的进程（GDB，netcat，getframe或者其他访问KGTP接口的进程）的时候，其将不执行任何actions。

如果你想让tracepoint actions和任何task的时候都执行，请包含一个包含一个访问到$self_trace的命令到actions中，也就是说增加下面的命令到actions中：

>teval $self_trace=0

用$kret trace函数的结尾

有时，因为内核是用优化编译的，所以在函数结尾设置tracepoint有时很困难。这时你可以用$kret帮助你。

$kret是一个类似$self_trace的特殊trace状态变量。当你在tracepoint action里设置它的值的时候，这个tracepoint将用kretprobe而不是kprobe注册。于是其就可以trace一个函数的结尾。

请 注意 这个tracepoint 必须用 "function_name" 的格式设置在函数的第一个地址上。

下面的部分是一个例子：

#"*(function_name)" format can make certain that GDB send the first address of function to KGTP.

(gdb) trace *vfs_read

(gdb) actions

>teval $kret=0

#Following part you can set commands that you want.

用 $ignore_error 和 $last_errno 忽略tstart的错误

当KGTP在tstart取得错误，这个命令将失败。

但有时我们需要忽略这个错误信息并让KGTP工作。例如：如果你在inline函数spin_lock设置tracepoint，这个tracepoint将被设置到很多地址上，有一些地址不能设置kprobe，于是它就会让tstart出错。这时你就可以用"$ignore_error"忽略这些错误。

最后一个错误信息将存在"$last_errno"中。

(gdb) tvariable $ignore_error=1

这个命令将打开忽略。

(gdb) tvariable $ignore_error=0

这个命令将关闭忽略。

使用 $cooked_clock 和 $cooked_rdtsc 取得不包含KGTP运行时间的时间信息

访问这两个trace状态变量可以取得不包含KGTP运行时间的时间信息，于是我们可以取得一段代码更真实的执行时间即使这个tracepoint的action比较复杂。

使用 $xtime_sec 和 $xtime_nsec 取得 timespec

访问trace状态变量将返回用getnstimeofday取得的timespec时间信息。

$xtime_sec 将返回timespec秒的部分。

$xtime_nsec 将返回timespec纳秒的部分。

如何 backtrace (stack dump)

每次你的程序做一个函数调用的时候， 这次调用的信息就会生成。这些信息包括调用函数的地址，调用参数，局部变量的值。这些信息被存储在我们称为栈帧的地方，栈帧是从调用栈中分配而来。

通过$bt收集栈并用GDB命令backtrace进行分析

因为这个方法更快（只在trace时候收集栈帧信息）而且可以分析出大部分的调用栈中的信息（前面介绍的栈信息都可以分析出来），所以时间你使用这个方法做栈分析。

首先我们需要在tracepoint action中增加命令收集栈。

GDB收集栈的通常命令是： 在x86_32, 下面的命令将收集512字节的栈内容。

>collect *(unsigned char *)$esp@512

在x86_64, 下面的命令将收集512字节的栈内容。

>collect *(unsigned char *)$rsp@512

在MIPS或者ARM, 下面的命令将收集512字节的栈内容。

>collect *(unsigned char *)$sp@512

这些命令很难记，而且不同的体系结构需要不同的命令。

KGTP有一个特殊trace状态变量$bt。如果tracepoint action访问到它，KGTP将自动收集$bt长度（默认值是512）的栈。下面这个action将收集512字节的栈内存：

>collect $bt

如果你想改变$bt的值，你可以在"tstart"使用下面这个GDB命令：

(gdb) tvariable $bt=1024

下面的部分是一个收集栈并用GDB进行分析的例子：

(gdb) target remote /sys/kernel/debug/gtp

(gdb) trace vfs_readdir

Tracepoint 1 at 0xffffffff8118c300: file /home/teawater/kernel2/linux/fs/readdir.c, line 24.

(gdb) actions

Enter actions for tracepoint 1, one per line.

End with a line saying just "end".

>collect $bt

>end

(gdb) tstart

(gdb) shell ls

1 crypto fs include kernel mm Module.symvers security System.map vmlinux

arch drivers hotcode.html init lib modules.builtin net sound usr vmlinux.o

block firmware hotcode.html~ ipc Makefile modules.order scripts source virt

(gdb) tstop

(gdb) tfind

Found trace frame 0, tracepoint 1

#0 vfs_readdir (file=0xffff8800c5556d00, filler=0xffffffff8118c4b0 <filldir>, buf=0xffff880108709f40)

at /home/teawater/kernel2/linux/fs/readdir.c:24

24 {

(gdb) bt

#0 vfs_readdir (file=0xffff8800c5556d00, filler=0xffffffff8118c4b0 <filldir>, buf=0xffff880108709f40)

at /home/teawater/kernel2/linux/fs/readdir.c:24

#1 0xffffffff8118c689 in sys_getdents (fd=<optimized out>, dirent=0x1398c58, count=32768) at /home/teawater/kernel2/linux/fs/readdir.c:214

#2 <signal handler called>

#3 0x00007f00253848a5 in ?? ()

#4 0x00003efd32cddfc9 in ?? ()

#5 0x00002c15b7d04101 in ?? ()

#6 0x000019c0c5704bf1 in ?? ()

#7 0x0000000900000000 in ?? ()

#8 0x000009988cc8d269 in ?? ()

#9 0x000009988cc9b8d1 in ?? ()

#10 0x0000000000000000 in ?? ()

(gdb) up

#1 0xffffffff8118c689 in sys_getdents (fd=<optimized out>, dirent=0x1398c58, count=32768) at /home/teawater/kernel2/linux/fs/readdir.c:214

214 error = vfs_readdir(file, filldir, &buf);

(gdb) p buf

$1 = {current_dir = 0x1398c58, previous = 0x0, count = 32768, error = 0}

(gdb) p error

$3 = -9

(gdb) frame 0

#0 vfs_readdir (file=0xffff8800c5556d00, filler=0xffffffff8118c4b0 <filldir>, buf=0xffff880108709f40)

at /home/teawater/kernel2/linux/fs/readdir.c:24

24 {

从这个例子，我们可以看到一些分析调用栈的GDB命令：

• bt 是GDB命令 backtrace 的别名，这个命令将打印stack中的信息：每一行是一个调用栈。

• up n 是向上移动n个帧。如果n是正数，则向外到更高的帧，一直到这个栈最大的一行。n的默认值是1。

• down n 是向下移动n个帧。如果n是正数，则向内到更低的帧，一直到最新创建的那个栈帧。n的默认值是1。

  is move n frames down the stack. For positive numbers n, this advances toward the innermost frame, to lower frame numbers, to frames that were created more recently. n defaults to one. 你可以把 down 缩写为 do。

• frame n 是选择帧n。帧0是最近创建的帧，帧1调用这个帧的帧。所以最高的帧是main。

你还可以看到当你用up，down或者frame来选择调用栈帧的时候，你可以输出不同帧的参数和局部变量。

要取得更多关于如何使用GDB分析调用栈的信息，请到http://sourceware.org/gdb/current/onlinedocs/gdb/Stack.html。

用$_ret来取得当前函数的调用函数的栈

如果你只想取得当前函数的调用函数的栈，可以用$_ret。

请 注意 使用$_ret的tracepoint不能设置在函数的第一个地址上。

例如：

(gdb) list vfs_read

360 }

361

362 EXPORT_SYMBOL(do_sync_read);

363

364 ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos)

365 {

366 ssize_t ret;

367

368 if (!(file->f_mode & FMODE_READ))

369 return -EBADF;

(gdb) trace 368

Tracepoint 2 at 0xffffffff8117a244: file /home/teawater/kernel2/linux/fs/read_write.c, line 368.

(gdb) actions

Enter actions for tracepoint 2, one per line.

End with a line saying just "end".

>collect $_ret

>end

(gdb) tstart

(gdb) tstop

(gdb) tfind

Found trace frame 0, tracepoint 2

#0 vfs_read (file=0xffff880141c46000, buf=0x359bda0 <Address 0x359bda0 out of bounds>, count=8192, pos=0xffff88012fa49f48)

at /home/teawater/kernel2/linux/fs/read_write.c:368

368 if (!(file->f_mode & FMODE_READ))

(gdb) bt

#0 vfs_read (file=0xffff880141c46000, buf=0x359bda0 <Address 0x359bda0 out of bounds>, count=8192, pos=0xffff88012fa49f48)

at /home/teawater/kernel2/linux/fs/read_write.c:368

#1 0xffffffff8117a3ea in sys_read (fd=<optimized out>, buf=<unavailable>, count=<unavailable>)

at /home/teawater/kernel2/linux/fs/read_write.c:469

Backtrace stopped: not enough registers or memory available to unwind further

(gdb) up

#1 0xffffffff8117a3ea in sys_read (fd=<optimized out>, buf=<unavailable>, count=<unavailable>)

at /home/teawater/kernel2/linux/fs/read_write.c:469

469 ret = vfs_read(file, buf, count, &pos);

(gdb) p ret

$2 = -9

我们可以看到调用vfs_read的函数是sys_read，函数sys_read的局部变量ret的值是-9。

用 $dump_stack 输出栈分析到printk里

因为这个方法需要在trace的时候分析栈并调用printk，所以它比较慢，不安全，不清晰也不能访问调用栈中的很多内容，所以我建议你使用上一部分介绍的方法

KGTP有一个特殊的trace状态变量$dump_stack，收集这个变量可以令GDB调用栈分析并用printk输出。 下面是一个让内核输出vfs_readdir栈分析的例子：

target remote /sys/kernel/debug/gtp

trace vfs_readdir

commands

collect $dump_stack

end

于是你的内核就会printk这样的信息：

[22779.208064] gtp 1:Pid: 441, comm: python Not tainted 2.6.39-rc3+ #46

[22779.208068] Call Trace:

[22779.208072] [<fe653cca>] gtp_get_var+0x4a/0xa0 [gtp]

[22779.208076] [<fe653d79>] gtp_collect_var+0x59/0xa0 [gtp]

[22779.208080] [<fe655974>] gtp_action_x+0x1bb4/0x1dc0 [gtp]

[22779.208084] [<c05b6408>] ? _raw_spin_unlock+0x18/0x40

[22779.208088] [<c023f152>] ? __find_get_block_slow+0xd2/0x160

[22779.208091] [<c01a8c56>] ? delayacct_end+0x96/0xb0

[22779.208100] [<c023f404>] ? __find_get_block+0x84/0x1d0

[22779.208103] [<c05b6408>] ? _raw_spin_unlock+0x18/0x40

[22779.208106] [<c02e0838>] ? find_revoke_record+0xa8/0xc0

[22779.208109] [<c02e0c45>] ? jbd2_journal_cancel_revoke+0xd5/0xe0

[22779.208112] [<c02db51f>] ? __jbd2_journal_temp_unlink_buffer+0x2f/0x110

[22779.208115] [<fe655c4c>] gtp_kp_pre_handler+0xcc/0x1c0 [gtp]

[22779.208118] [<c05b8a88>] kprobe_exceptions_notify+0x3d8/0x440

[22779.208121] [<c05b7d54>] ? hw_breakpoint_exceptions_notify+0x14/0x180

[22779.208124] [<c05b95eb>] ? sub_preempt_count+0x7b/0xb0

[22779.208126] [<c0227ac5>] ? vfs_readdir+0x15/0xb0

[22779.208128] [<c0227ac4>] ? vfs_readdir+0x14/0xb0

[22779.208131] [<c05b9743>] notifier_call_chain+0x43/0x60

[22779.208134] [<c05b9798>] __atomic_notifier_call_chain+0x38/0x50

[22779.208137] [<c05b97cf>] atomic_notifier_call_chain+0x1f/0x30

[22779.208140] [<c05b980d>] notify_die+0x2d/0x30

[22779.208142] [<c05b71c5>] do_int3+0x35/0xa0

如何让tracepoint直接输出信息

在前面的章节，你可以看到如果想取得Linux内核的信息，你需要用tracepoint "collect" action来保存信息到tracepoint帧中并用GDB tfind命来来分析这些数据帧。

但是有时我们希望直接取得这些数据，所以KGTP提供了一种直接取得这些数据的方法。

切换collect为直接输出数据

KGTP有特殊trace状态变量$printk_level，$printk_format 和 $printk_tmp支持这个功能。

$printk_level，如果这个值是8（这是默认值），"collect" action将是普通行为也就是保存数据到tracepoint帧中。

如果值是0-7，"collect" 将以这个数字为printk级别输出信息，这些级别是：

0 KERN_EMERG system is unusable

1 KERN_ALERT action must be taken immediately

2 KERN_CRIT critical conditions

3 KERN_ERR error conditions

4 KERN_WARNING warning conditions

5 KERN_NOTICE normal but significant condition

6 KERN_INFO informational

7 KERN_DEBUG debug-level messages

$printk_format，collect printk将按照这里设置的格式进行输出。 这些格式是：

0 这是默认值。

如果collect的长度是1，2，4，8则其将输出一个无符号十进制数。

如果不是，则其将输出十六进制字串。

1 输出值是有符号十进制数。

2 输出值是无符号十进制数。

3 输出值是无符号十六进制数。

4 输出值是字符串。

5 输出值是十六进制字串。

如果要输出一个全局变量，需要将其先设置到$printk_tmp中。

下面是一个显示调用vfs_readdir时的计数，pid，jiffies_64和文件名的例子：

(gdb) target remote /sys/kernel/debug/gtp

(gdb) tvariable $c

(gdb) trace vfs_readdir

(gdb) actions

>teval $printk_level=0

>collect $c=$c+1

>collect ((struct task_struct *)$current_task)->pid

>collect $printk_tmp=jiffies_64

>teval $printk_format=4

>collect file->f_path.dentry->d_iname

>end

于是内核将printk这些信息：

gtp 1:$c=$c+1=41

gtp 1:((struct task_struct *)$current_task)->pid=12085

gtp 1:$printk_tmp=jiffies_64=4322021438

gtp 1:file->f_path.dentry->d_iname=b26

gtp 1:$c=$c+1=42

gtp 1:((struct task_struct *)$current_task)->pid=12085

gtp 1:$printk_tmp=jiffies_64=4322021438

gtp 1:file->f_path.dentry->d_iname=b26

"gtp 1" 的意思是数据是tracepoint 1输出的。

如何用watch tracepoint控制硬件断点记录内存访问

Watch tracepoint 可以通过设置一些特殊的trace状态变量设置硬件断点来记录内存访问。

请 注意 watch tracepoint现在只有X86和X86_64支持。而且因为Linux 2.6.26和更老版本有一些IPI的问题，只有Linux 2.6.27和更新版本上可以正常使用动态watch tracepoint。

watch tracepoint的trace状态变量

静态watch tracepoint

当你要监视全局变量或者可以取得地址的变量的值的时候，你可以使用静态watch tracepoint。下面是一个监视jiffies_64写的例子:

#静态watch tracepoint从tracepoint的地址中取得要监视的地址

trace *&jiffies_64

actions

#Set this watch tracepoint to static

teval $watch_static=1

#Watch memory write

teval $watch_type=1

teval $watch_size=8

collect $watch_val

collect $watch_prev_val

collect $bt

end

动态watch tracepoint

当你要监视局部变量或者只能在函数中取得地址的变量的值的时候，你可以使用动态watch tracepoint。下面是一个监视函数function get_empty_filp中f->f_posf->f_op写的例子:

trace *1

commands

teval $watch_static=0

teval $watch_type=1

teval $watch_size=8

collect $bt

collect $watch_addr

collect $watch_val

collect $watch_prev_val

end

定义了一个动态watch tracepoint。地址"1"并不是其要监视的地址。其将帮助tracepoint来找到这个动态watch tracepoint。

list get_empty_filp

trace 133

commands

teval $watch_set_addr=1

teval $watch_size=4

teval $watch_start=&(f->f_pos)

teval $watch_size=8

teval $watch_start=&(f->f_op)

end

在函数get_empty_filp中定义一个普通tracepoint，其将开始监视f->f_pos和f->f_op。

trace file_sb_list_del

commands

teval $watch_stop=&(file->f_pos)

teval $watch_stop=&(file->f_op)

end

在函数file_sb_list_del中定义一个普通tracepoint，其将停止监视file->f_pos和file->f_op。

使用while-stepping让Linux内核做单步

请 注意 while-stepping现在只有X86和X86_64支持。

介绍使用while-stepping的视频 http://www.codepark.us/a/12。

如何使用 while-stepping

while-stepping 是一种可以包含actions的特殊tracepoint action。

当一个actions中包含了“while-stepping n”的tracepoint执行的时候，其将做n次单步并执行while-stepping的actions。例如：

trace vfs_read

#因为单步会影响系统速度，所以最好用passcount或者condition限制tracepoint的执行次数。

passcount 1

actions

collect $bt

collect $step_count

#做2000次单步。

while-stepping 2000

#下面这部分是"while-stepping 2000"的actions。

#因为单步可能会执行到其他函数，所以最好不要访问局部变量。

collect $bt

collect $step_count

end

end

请 注意 tracepoint在执行单步的时候会关闭当前CPU的中断。 在actions中访问 $step_count 将得到从1开始的这步的计数。

读while-stepping的traceframe

不同step的数据将会被记录到不同的traceframe中，你可以用tfind (用tfind选择trace帧缓存里面的条目) 选择他们。

或者你可以将KGTP切换到回放模式，这样GDB可以用执行和反向执行命令选择一个while-stepping tracepoint的traceframe。例如：

用tfind选择一个while-stepping的traceframe。

(gdb) tfind

Found trace frame 0, tracepoint 1

#0 vfs_read (file=0xffff8801f7bd4c00, buf=0x7fff74e4edb0 <Address 0x7fff74e4edb0 out of bounds>, count=16,

pos=0xffff8801f4b45f48) at /build/buildd/linux-3.2.0/fs/read_write.c:365

365 {

下面的命令将切换KGTP到回放模式。

(gdb) monitor replay

(gdb) tfind -1

No longer looking at any trace frame

#0 vfs_read (file=0xffff8801f7bd4c00, buf=0x7fff74e4edb0 <Address 0x7fff74e4edb0 out of bounds>, count=16,

pos=0xffff8801f4b45f48) at /build/buildd/linux-3.2.0/fs/read_write.c:365

365 {

于是可以使用执行命令。

(gdb) n

368 if (!(file->f_mode & FMODE_READ))

(gdb) p file->f_mode

$5 = 3

设置断点 (只在回放模式下有效，不会影响到Linux内核执行)。

(gdb) b 375

Breakpoint 2 at 0xffffffff81179b75: file /build/buildd/linux-3.2.0/fs/read_write.c, line 375.

(gdb) c

Continuing.

Breakpoint 2, vfs_read (file=0xffff8801f7bd4c00, buf=0x7fff74e4edb0 <Address 0x7fff74e4edb0 out of bounds>, count=16,

pos=0xffff8801f4b45f48) at /build/buildd/linux-3.2.0/fs/read_write.c:375

375 ret = rw_verify_area(READ, file, pos, count);

(gdb) s

rw_verify_area (read_write=0, file=0xffff8801f7bd4c00, ppos=0xffff8801f4b45f48, count=16)

at /build/buildd/linux-3.2.0/fs/read_write.c:300

300 inode = file->f_path.dentry->d_inode;

使用反向执行命令。

(gdb) rs

Breakpoint 2, vfs_read (file=0xffff8801f7bd4c00, buf=0x7fff74e4edb0 <Address 0x7fff74e4edb0 out of bounds>, count=16,

pos=0xffff8801f4b45f48) at /build/buildd/linux-3.2.0/fs/read_write.c:375

375 ret = rw_verify_area(READ, file, pos, count);

(gdb) rn

372 if (unlikely(!access_ok(VERIFY_WRITE, buf, count)))

GDB命令tstart，tstop，tfind或者quit可以自动关闭回放模式。

如何显示被优化掉的变量值

有时GDB会这样输出信息：

inode has been optimized out of existence.

res has been optimized out of existence.

这是因为inode和res的值被优化掉了。内核用-O2编译的所以你有时会碰到这个问题。

有两个方法处理这个问题：

升级你的GCC

VTA branch http://gcc.gnu.org/wiki/Var_Tracking_Assignments 已经整合进GCC 4.5，其可以帮助生成之前被标记为"optimized out"的值的调试信息。

通过分析汇编代码取得访问被优化掉变量的方法

即使升级了GCC，你可能还会遇到问题。主要原因是数据在寄存器中但是GCC没有把信息放到调试信息中。所以GDB只能显示这个变量被又优化掉了。

但你可以通过分析汇编代码取得这个变量在哪并在tracepoint actions中访问其。

下面是一个在函数get_empty_filp中寻找变量"f"并在tracepoint actions中使用其的例子：

我们想collect变量f的值，但是其已经被优化掉了。

(gdb) list get_empty_filp

...

...

...

137 INIT_LIST_HEAD(&f->f_u.fu_list);

138 atomic_long_set(&f->f_count, 1);

139 rwlock_init(&f->f_owner.lock);

140 spin_lock_init(&f->f_lock);

141 eventpoll_init_file(f);

(gdb)

142 /* f->f_version: 0 */

143 return f;

(gdb) trace 143

Tracepoint 1 at 0xffffffff8119b30e: file fs/file_table.c, line 143.

(gdb) actions

Enter actions for tracepoint 1, one per line.

End with a line saying just "end".

>collect f

`f' is optimized away and cannot be collected.

现在用"disassemble /m"命令取得和"f"有关的汇编代码和源码并分析他们。

(gdb) disassemble /m get_empty_filp

...

...

...

125 f = kmem_cache_zalloc(filp_cachep, GFP_KERNEL);

126 if (unlikely(!f))

0xffffffff8119b28c <+92>: test %rax,%rax

0xffffffff8119b292 <+98>: je 0xffffffff8119b362 <get_empty_filp+306>

127 return ERR_PTR(-ENOMEM);

0xffffffff8119b362 <+306>: mov $0xfffffffffffffff4,%rax

0xffffffff8119b369 <+313>: jmp 0xffffffff8119b311 <get_empty_filp+225>

因为"+98"到"+132"的代码因为属于inline函数所以没有在这里显示，但是你可以用"disassemble get_empty_filp"取得他们。

0xffffffff8119b287 <+87>: callq 0xffffffff81181cb0 <kmem_cache_alloc>

0xffffffff8119b28c <+92>: test %rax,%rax

0xffffffff8119b28f <+95>: mov %rax,%rbx

0xffffffff8119b292 <+98>: je 0xffffffff8119b362 <get_empty_filp+306>

0xffffffff8119b298 <+104>: mov 0xb4d406(%rip),%edx # 0xffffffff81ce86a4 <percpu_counter_batch>

0xffffffff8119b29e <+110>: mov $0x1,%esi

0xffffffff8119b2a3 <+115>: mov $0xffffffff81c05340,%rdi

---Type <return> to continue, or q <return> to quit---

0xffffffff8119b2aa <+122>: callq 0xffffffff8130dd20 <__percpu_counter_add>

根据汇编代码你可以看到kmem_cache_alloc的返回值在$rax中，其的值被设置到了$rbx中。

看起来$rbx有"f"的值，让我们看其他的汇编代码。

128

129 percpu_counter_inc(&nr_files);

130 f->f_cred = get_cred(cred);

0xffffffff8119b2b4 <+132>: mov %r12,0x70(%rbx)

设置一个值到f的元素中。汇编代码是设置$r12的值到以$rbx为基础地址的内存中。其让$rbx看起来是"f"。

131 error = security_file_alloc(f);

0xffffffff8119b2b8 <+136>: mov %rbx,%rdi

0xffffffff8119b2bb <+139>: callq 0xffffffff8128ee30 <security_file_alloc>

132 if (unlikely(error)) {

0xffffffff8119b2c0 <+144>: test %eax,%eax

0xffffffff8119b2c2 <+146>: jne 0xffffffff8119b36b <get_empty_filp+315>

---Type <return> to continue, or q <return> to quit---

133 file_free(f);

134 return ERR_PTR(error);

0xffffffff8119b393 <+355>: movslq -0x14(%rbp),%rax

0xffffffff8119b397 <+359>: jmpq 0xffffffff8119b311 <get_empty_filp+225>

135 }

136

137 INIT_LIST_HEAD(&f->f_u.fu_list);

138 atomic_long_set(&f->f_count, 1);

139 rwlock_init(&f->f_owner.lock);

0xffffffff8119b2e4 <+180>: movl $0x100000,0x50(%rbx)

140 spin_lock_init(&f->f_lock);

0xffffffff8119b2c8 <+152>: xor %eax,%eax

0xffffffff8119b2d1 <+161>: mov %ax,0x30(%rbx)

141 eventpoll_init_file(f);

142 /* f->f_version: 0 */

143 return f;

0xffffffff8119b30e <+222>: mov %rbx,%rax

在检查了其他汇编代码后，你可以确定$rbx就是"f"。

于是你可以在tracepoint actions中通过访问$rbx而访问"f"，例如：

(gdb) trace 143

Tracepoint 1 at 0xffffffff8119b30e: file fs/file_table.c, line 143.

(gdb) actions

Enter actions for tracepoint 1, one per line.

End with a line saying just "end".

#collect f

>collect $rbx

#collect *f

>collect *((struct file *)$rbx)

#collect f->f_op

>collect ((struct file *)$rbx)->f_op

>end

如何取得函数指针指向的函数

如果函数指针没有被优化掉

你可以直接collect这个指针，例如：

377 count = ret;

378 if (file->f_op->read)

379 ret = file->f_op->read(file, buf, count, pos);

(gdb)

(gdb) trace 379

Tracepoint 1 at 0xffffffff81173ba5: file /home/teawater/kernel/linux/fs/read_write.c, line 379.

(gdb) actions

Enter actions for tracepoint 1, one per line.

End with a line saying just "end".

>collect file->f_op->read

>end

(gdb) tstart

(gdb) tstop

(gdb) tfind

(gdb) p file->f_op->read

$5 = (ssize_t (*)(struct file *, char *, size_t, loff_t *)) 0xffffffff81173190 <do_sync_read>

#于是就知道file->f_op->read指向do_sync_read。

如果函数指针被优化掉了

可以用tracepoint step处理这个问题，例如：

#找到调用指针的指令

(gdb) disassemble /rm vfs_read

379 ret = file->f_op->read(file, buf, count, pos);

0xffffffff81173ba5 <+181>: 48 89 da mov %rbx,%rdx

0xffffffff81173ba8 <+184>: 4c 89 e9 mov %r13,%rcx

0xffffffff81173bab <+187>: 4c 89 e6 mov %r12,%rsi

0xffffffff81173bae <+190>: 4c 89 f7 mov %r14,%rdi

0xffffffff81173bb1 <+193>: ff d0 callq *%rax

0xffffffff81173bb3 <+195>: 48 89 c3 mov %rax,%rbx

(gdb) trace *0xffffffff81173bb1

Tracepoint 1 at 0xffffffff81173bb1: file /home/teawater/kernel/linux/fs/read_write.c, line 379.

(gdb) actions

Enter actions for tracepoint 1, one per line.

End with a line saying just "end".

>while-stepping 1

>collect $reg

>end

>end

(gdb) tstart

(gdb) tstop

(gdb) tfind

#0 tty_read (file=0xffff88006ca74900, buf=0xb6b7dc <Address 0xb6b7dc out of bounds>, count=8176,

ppos=0xffff88006e197f48) at /home/teawater/kernel/linux/drivers/tty/tty_io.c:960

960 {

#于是就知道file->f_op->read指向tty_read。

请 注意 while-stepping 将让tracepoint不能使用kprobes-optimization。

/sys/kernel/debug/gtpframe和离线调试

/sys/kernel/debug/gtpframe是一个当KGTP停止时的tfind格式（GDB可以读取它）的接口。

在运行GDB的主机上：

改变 "target remote XXXX" 为：

(gdb) target remote | perl ./getgtprsp.pl

之后像平时一样设置tracepoint：

(gdb) trace vfs_readdir

Tracepoint 1 at 0xffffffff8114f3c0: file /home/teawater/kernel/linux-2.6/fs/readdir.c, line 24.

(gdb) actions

Enter actions for tracepoint 1, one per line.

End with a line saying just "end".

#If your GDB support tracepoint "printf" (see "Howto use tracepoint printf"), use it to show the value directly is better.

>collect $reg

>end

(gdb) tstart

(gdb) stop

(gdb) quit

于是你可以在当前目录找到文件gtpstart和gtpstop，把他们拷贝到你想调试的主机上。

在被调试主机上，先拷贝KGTP目录中的程序"putgtprsp"和"gtp.ko"到这台机器上。insmod gtp.ko之后：

启动tracepoint：

./putgtprsp ./gtpstart

停止tracepoint：

./putgtprsp ./gtpstop

可以按照如何让tracepoint直接输出信息直接在板子上显示信息。

如果要保存trace帧之后再分析，你可以拷贝文件"/sys/kernel/debug/gtpframe"到有GDB的主机上。

请 注意 有些"cp"不能很好的处理这个问题，可以用"cat /sys/kernel/debug/gtpframe > ./gtpframe"拷贝它。

在运行GDB的主机上：

(gdb) target tfile ./gtpframe

Tracepoint 1 at 0xffffffff8114f3dc: file /home/teawater/kernel/linux-2.6/fs/readdir.c, line 24.

Created tracepoint 1 for target's tracepoint 1 at 0xffffffff8114f3c0.

(gdb) tfind

Found trace frame 0, tracepoint 1

#0 vfs_readdir (file=0xffff880036e8f300, filler=0xffffffff8114f240 <filldir>, buf=0xffff880001e5bf38)

at /home/teawater/kernel/linux-2.6/fs/readdir.c:24

24 {

请 注意 如果你想在使用离线调试后从远程主机上的GDB连接KGTP，你需要在调用"nc"之前"rmmod gtp"和"insmod gtp.ko"。

如何使用 /sys/kernel/debug/gtpframe_pipe

这个接口提供和"gtpframe"同样的数据，但是可以在KGTP tracepoint运行的时候也可以使用。在数据读出之后，其将自动从trace帧里删除类似ftrace "trace_pipe"。

用GDB读帧信息

#连接到接口上

(gdb) target tfile /sys/kernel/debug/gtpframe_pipe

#取得一个trace帧条目

(gdb) tfind 0

Found trace frame 0, tracepoint 1

#取得下一个

(gdb) tfind

Target failed to find requested trace frame.

(gdb) tfind 0

Found trace frame 0, tracepoint 1

这个方法和python一起分析内核比较好，add-ons/hotcode.py就是这样的例子。

用cat读帧信息

sudo cat /sys/kernel/debug/gtpframe_pipe > g

于是所有帧信息都被存入了文件"g"。

用getframe读帧信息

KGTP包含一个"getframe"可以用来帮助取得trace帧。

下面这里是它的帮助：

getframe -h

Get the trace frame of KGTP and save them in current

directory with tfile format.

Usage: ./getframe [option]

-g n Set the minimum free size limit to n G.

When free size of current disk is smaller than n G,

./getframe will exit (-q) or wait some seconds (-w).

The default value of it is 2 G.

-q Quit when current disk is smaller than

minimum free size limit (-g).

-w n Wait n seconds when current disk is smaller

than minimum free size limit (-g).

-e n Set the entry number of each tfile to n.

The default value of it is 1000.

-h Display this information.

使用 $pipe_trace

为了锁安全，KGTP默认将自动忽略读/sys/kernel/debug/gtpframe_pipe的任务。

如果你真希望trace这个任务而且确定这是安全的，你可以使用"tstart"之前使用下面的命令：

(gdb) tvariable $pipe_trace=1

于是KGTP将不再忽略读/sys/kernel/debug/gtpframe_pipe的任务。

和用户程序一起使用KGTP

KGTP可以在不停止用户程序的情况下，访问内存和trace这个应用层程序。

让GDB为访问用户程序而连接KGTP

1) 在 不装载 任何应用程序的情况下打开GDB。

2) 如果用户程序在本机运行，则使用GDB命令 "target extended-remote /sys/kernel/debug/gtp" 连接KGTP。 如果用户程序运行在远程主机上，则使用类似 如果GDB在远程主机上 的方法但是需要将 "target remote" 替换为 "target extended-remote"。

3) 用GDB命令 "file" 装载用户程序 (其必须在编译时候增加GCC参数"-g"保证其有调试信息)。

4) 用GDB命令 "attach pid" 来attach上task的pid。

因此让GDB为访问用户程序而连接KGTP的步骤将是：

sudo gdb-release

(gdb) target extended-remote /sys/kernel/debug/gtp

Remote debugging using /sys/kernel/debug/gtp

0x00000000 in ?? ()

(gdb) file a.out

A program is being debugged already.

Are you sure you want to change the file? (y or n) y

Reading symbols from /home/teawater/kernel/kgtp/a.out...done.

(gdb) attach 15412

A program is being debugged already. Kill it? (y or n) y

Attaching to program: /home/teawater/kernel/kgtp/a.out, Remote target

# 一些版本的GDB可能会出现internal-error，请回答 "n" 来忽略他们。

直接读用户程序的内存

在GDB attach用户程序成功后，你可以用GDB命令"p"和"x"访问到这个task的内存。你可以用GDB命令"help p"和"help x"取得这两个命令的帮助。例如：

(gdb) p c

$19 = 4460

(gdb) p &c

$21 = (int *) 0x601048 <c>

(gdb) x 0x601048

0x601048 <c>: 0x00001181。

Trace用户程序

KGTP用Linux内核功能 uprobes 来trace用户程序，只有Linux内核3.9或者更新版本支持这个功能。

大部分Linux发行版所使用的内核(3.9或者更新版本)的编译选项都打开了 uprobes 。

如果是自己编译的内核：

Kernel hacking --->

[*] Tracers --->

[*] Enable uprobes-based dynamic events

如果当前Linux内核的 uprobes 是打开的，可以在attach上用户程序后根据 GDB tracepoint 设置tracepoint。例如：

(gdb) trace 14

Tracepoint 1 at 0x400662: file /home/teawater/kernel/kgtp-misc/test.c, line 14.

(gdb) actions

Enter actions for tracepoint 1, one per line.

End with a line saying just "end".

>collect $bt

>collect c

>end

(gdb) tstart

(gdb) tstatus

Trace is running on the target.

Collected 5 trace frames.

Trace buffer has 20824428 bytes of 20828160 bytes free (0% full).

Trace will stop if GDB disconnects.

Not looking at any trace frame.

(gdb) tstop

(gdb) tfind

Found trace frame 0, tracepoint 1

#0 main (argc=1, argv=0x7fff5e878368, envp=0x7fff5e878378) at /home/teawater/kernel/kgtp-misc/test.c:14

14 c += 1;

(gdb) bt

#0 main (argc=1, argv=0x7fff5e878368, envp=0x7fff5e878378) at /home/teawater/kernel/kgtp-misc/test.c:14

(gdb) p c

$7 = 36

请注意即使你只attach了一个task，用户层tracepoint会在这个用户程序的所有task上上触发。(我认为这是 uprobes 的一个很有趣的特色，所以我没在KGTP tracepoint中对其进行限制。)

你可以在tracepoint conditions中增加对$current_task_pid的检查来让tracepoint只在某task上被触发。下面的例子就是一个设置只在task 985上触发tracepoint上的例子：

(gdb) trace 14

Tracepoint 1 at 0x400662: file /home/teawater/kernel/kgtp-misc/test.c, line 14.

(gdb) condition $bpnum ($current_task_pid == 985)

同时你还可以在tracepoint actions中增加"collect $current_task_pid"来确定哪个task触发了这个tracepoint。例如：

(gdb) trace 14

Tracepoint 2 at 0x400662: file /home/teawater/kernel/kgtp-misc/test.c, line 14.

(gdb) actions

Enter actions for tracepoint 2, one per line.

End with a line saying just "end".

>collect $current_task_pid

>collect c

>end

(gdb) tstart

(gdb) tstatus

Trace is running on the target.

Collected 6 trace frames.

Trace buffer has 20827776 bytes of 20828160 bytes free (0% full).

Trace will stop if GDB disconnects.

Not looking at any trace frame.

(gdb) tstop

(gdb) tfind