通常调试问题的时候，经常会遇到链表，而gdb调试链表的手动计算和填入，非常麻烦。但是pwndbg提供了一个非常好的命令telescope会帮我们自动解析链表。
# telescope打印链表的条件
编程者在设计链表的时候结构各种各样，所以并不是每一种链表都是能够轻松打印的，但是一种简单的方式可以打印链表，那就是无限取值。下面介绍一下。

假设0xaaa地址的值是0xbbb，那么取到0xbbb之后，再读0xbbb的值0xccc，然后再读0xccc的值0xddd，依此类推。

这就是无限取值，它和打印链表有什么关系呢。

一个常用的双向链表如下
```
pwndbg> ptype list
type = struct list_head {
    struct list_head *prev;
    struct list_head *next;
} *
```
我们打印一下偏移值，如下
```
pwndbg> ptype /o list
type = struct list_head {
/*    0      |     8 */    struct list_head *prev;
/*    8      |     8 */    struct list_head *next;

                           /* total size (bytes):   16 */
                         } *
```
可以看到，list_head的prev永远是list_head的取值，也就意味着对list_head的无限取值就是获取list_head的prev链表的遍历。
# 实践
首先需要一个体现双向链表的示例代码，可以以之前写的lru算法为例
```
git clone https://github.com/tangfeng-648/lru.git
```
直接调试
```
gdb ./lru
```
为了方便调试，这里直接在list_add加上断点
```
pwndbg> b list_add
Breakpoint 1 at 0x400814: file list.h, line 24.
```
此时断点触发情况如下
```
   22 static inline void list_add(struct list_head *item, struct list_head *list)
   23 {
 ► 24     item->prev = list;
   25     item->next = list->next;
   26     list->next->prev = item;
   27     list->next = item;
   28 }
```
利用list可以打印这个list_head，如下
```
pwndbg> telescope list 1
00:0000│ x1 0x4132b8 —▸ 0x413e38 —▸ 0x413e68 —▸ 0x413e98 —▸ 0x413ec8 ◂— ...
pwndbg> telescope 0x413ec8 1
00:0000│  0x413ec8 —▸ 0x413ef8 —▸ 0x413f28 —▸ 0x413f58 —▸ 0x413f88 ◂— ...
```
因为list_head的偏移0是`struct list_head *prev`，所以telescope实际上是对这个list的逆序查找。

下面验证一下是否正确，如下
```
pwndbg> p list
$1 = (struct list_head *) 0x4132b8
pwndbg> p list->prev
$2 = (struct list_head *) 0x413e38
pwndbg> p list->prev->prev
$3 = (struct list_head *) 0x413e68
pwndbg> p list->prev->prev->prev
$4 = (struct list_head *) 0x413e98
pwndbg> p list->prev->prev->prev->prev
$5 = (struct list_head *) 0x413ec8
pwndbg> p list->prev->prev->prev->prev->prev
$6 = (struct list_head *) 0x413ef8
pwndbg> p list->prev->prev->prev->prev->prev->prev
$7 = (struct list_head *) 0x413f28
pwndbg> p list->prev->prev->prev->prev->prev->prev->prev
$8 = (struct list_head *) 0x413f58
pwndbg> p list->prev->prev->prev->prev->prev->prev->prev->prev
$9 = (struct list_head *) 0x413f88
```
可以看到，telescope相当于隐式的帮我们打印了这个链表。
# 如何打印next
实际上因为next相比于prev每次都要加上8的偏移，默认情况下pwndbg没有提供这样的命令，只能自行手动计算。
# 总结
本文分享了一个简单的方法来打印链表，实际上，是否能够打印链表，取决于自己对内存布局是否熟悉，如果很熟悉的情况下，可以借助这个命令简化自己的计算，如果不熟悉的情况下，建议还是手动计算吧。否则telescope给你的信息并不一定对你有用。







gdb调试方法(9)-打印链表

gdb调试方法(8)-pwndbg

在实际的gdb调试经验中，更多是多线程的调试方式，因为系统很多的设计都是基于线程的，所以某个二进制存在问题，通常存在与某个线程中，此时gdb需要正确的切换到对应线程中，然后运行。

如果只是切换到某个线程，然后调试，这个其实按照之前的文章就能够达成调试的目的，但是通常而言，需要针对某个线程做一些特殊处理，例如暂停线程，观察某个线程，观察变量。本文主要介绍这些。

# 示例代码
为了介绍这些技巧，需要准备一个多线程示例程序，如下
```
#include <stdio.h>
#include <unistd.h>
#include <pthread.h>
int a = 0;
int b = 0;
void *thread1_func(void *p_arg) 
{
    while (1) {
        a++;
        sleep(1);
    }
}

void *thread2_func(void *p_arg) 
{
    while (1) {
        b++;
        a=b;
        sleep(1);
    }
}

int main(void)
{
        pthread_t t1, t2;
        pthread_create(&t1, NULL, thread1_func, "Thread 1");
        pthread_create(&t2, NULL, thread2_func, "Thread 2");
        pthread_join(t1, NULL);
        pthread_join(t2, NULL);
}
```
编译即可
```
gcc threads.c -lpthread -g -o threads
```
# 让关心的线程运行，其他线程停止
在调试过程中，我们可以针对自己关心的线程来调试，停掉其他所有运行的线程，从而做一个排除无关因素来定位代码。主要方式如下
```
set scheduler-locking on
b 9
```
此时根据断点在第9行`a++`，此时断点触发后，b的值是恒定为1的。如下
```
(gdb) p b
$1 = 1
```
可以看到，这样的情况下，代码的两个线程并不会在continue的时候同时运行，而是停掉了thread2的运行，只运行thread1。

这种情况下，如果我们怀疑某些代码是某个线程导致的，那么可以根据此来进行排除法，从而能够很快的确定问题范围

# 让关心的线程停止，其他线程运行
和让关心的线程运行不一样的是，如果我们只是调试某个线程，但不想把所有线程停止，那么可以让其他线程运行，而自己关心的线程停止，从而调试查看变量。如下
```
(gdb) set non-stop on
(gdb) r
(gdb) set scheduler-locking off
(gdb) b threads.c:16
```
此时我们查看线程状态，可以看到thread1是运行的，而断点的thread2是停止的，如下
```
(gdb) info threads
  Id   Target Id                                     Frame
* 1    Thread 0xfffff7ff7010 (LWP 3262267) "threads" __pthread_clockjoin_ex (threadid=281474840293856, thread_return=0x0, clockid=0, abstime=<optimized out>, block=<optimized out>) at pthread_join_common.c:145
  2    Thread 0xfffff7de71e0 (LWP 3262274) "threads" (running)
  3    Thread 0xfffff75e61e0 (LWP 3262275) "threads" thread2_func (p_arg=0xaaaaaaaaaaf0) at threads.c:17
```
所以我们查看b的值是不变的，而a的值是不断更新的。如下
```
(gdb) p b
$1 = 19
(gdb) p a
$2 = 96
(gdb) p a
$3 = 99
(gdb) p b
$4 = 19
```
# 设置观察点
在调试时，经常需要为某个变量在其作用域内设置观察点，通常而言，观察点会导致整体程序运行过慢，甚至导致代码跑飞，所以需要打上硬件观察点awatch和rwatch，而读写观察点和读观察点需要根据业务来判断，通常读观察点性能稍高一点。

但是在使用观察点的时候，还需要注意作用域，离开变量作用域的观察点就会无效。所以局部变量的观察点需要单独讨论，这里先讨论全局变量的观察点。

在多线程中，全局变量是共享数据的，这种情况下，观察点会在每个线程生效，但是如果我只想观察某个线程的全局变量，可以为这个观察点设置仅在某个线程下生效。
```
(gdb) awatch a thread 3
Hardware access (read/write) watchpoint 2: a
(gdb) c
Continuing.
[Switching to Thread 0xfffff75e61e0 (LWP 3349970)]

Thread 3 "threads" hit Hardware access (read/write) watchpoint 2: a

Value = 10
(gdb) c
Continuing.

Thread 3 "threads" hit Hardware access (read/write) watchpoint 2: a

Value = 11
```
可以看到，如果指定了thread 3，那么a的读写观察点只会在thread 3 中被触发。这样就相当于设置了仅某线程生效的观察点。从而方便自己排查问题。
# 总结
通常很多大型程序都是多线程的，当存在性能问题，或者崩溃问题时，需要使用gdb排查，但是gdb在多线程排查的时候需要一些技巧，否则每次定位程序都比较复杂，本文介绍了能够提高多线程调试效率的办法，从而能够让gdb在多线程调试时，判断问题直接了当，不浪费时间。


gdb调试方法(7)-多线程调试

只要有了良好的调试信息，那么使用gdb调试就会变得非常简单，本文基于此再介绍在操作系统更常见和常使用的调试技巧
# 编译环境和运行环境
在讨论常用的调试技巧之前，我们必须清楚什么是编译环境，什么是运行环境，基本上所有的操作系统发行时，编译环境一定不是运行环境，操作系统发行方来保证编译环境和运行环境的基础库尽可能一致。

但是对于gdb的调试者而言，这里就会存在一个常见的问题，因为部署在某嵌入式操作系统上的软件的编译环境和运行环境路径不一致，此时即使二进制存在DWARF调试信息，也没办法准确的查看到行号。 下面举个例子说明

# 示例代码
为了演示这个问题，需要准备example_print.c文件，内容如下
```
#include <stdio.h>

int func1(int a)
{
  int array[100];
  int i;

  for (i = 0; i < 100; i++)
    array[i] = i;

  return array[99] * a;
}

int func2(int a)
{
  int b = 2;
  return b * func1(a);
}

int func3(int a)
{
  int b = 3;
  return b * func2(a);
}

int main(void)
{
  printf("%d\n", func3(10));
  return 0;
}
```
我们将其编译带上DWARF调试信息，如下
```
gcc example_print.c -g -o print
```
此时我们将其放置到运行环境中，gdb调试它，如下
```
scp print kylin@91:~
```
使用gdb加载时，可以看到DWARF的line info失效了。
```
# gdb ./print
Reading symbols from ./print...
(gdb) l
14      example_print.c: 没有那个文件或目录.
```
# 处理行号问题
上述这种情况下，我们需要将对应的源码获取，如下
```
scp example_print.c kylin@91:~
```
然后使用directory命令加载即可
```
(gdb) directory ~/.
(gdb) l
14      int func2(int a)
15      {
16        int b = 2;
17        return b * func1(a);
18      }
```
到这里，我们解决了在操作系统上非常常见的无源码行号的问题。
# 简单调试
当我们准备好对应某个源码行号之后，可以做一些基础的调试，下面分析非常常见的调试方法
## 打印数组的值
在上述代码中，数组array会被i赋值，如果我们想要分析其中某个值，例如`array[55]`可以如下
```
(gdb) u 11
(gdb) p array[55]@1
$4 = {55}
```
可以看到，这样能够轻松的查找内存的想要的内容
## 打印堆栈中的局部变量
在上面代码中，每个函数都附带了局部变量，我们可以直接在最底层堆栈中打印其上层堆栈的局部变量，如下
```
(gdb) frame
#0  func1 (a=10) at example_print.c:11
11        return array[99] * a;
(gdb) bt
#0  func1 (a=10) at example_print.c:11
#1  0x00000055555508f0 in func2 (a=10) at example_print.c:17
#2  0x0000005555550920 in func3 (a=10) at example_print.c:23
#3  0x0000005555550944 in main () at example_print.c:28
(gdb) p func2::b
$5 = 2
(gdb) p func3::b
$6 = 3
(gdb) p func1::array
$7 = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59,
  60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99}
(gdb) p func1::i
$8 = 100
```
可以看到，代码当前在的func1的栈上，但是gdb能够帮我们计算好其所有堆栈的局部变量，我们直接打印即可。
## 主动调用函数
在调试大型代码时，有些函数可以自己手动调用，这样就不用重跑一次gdb了，如下
```
(gdb) set var a=100
(gdb) frame
#0  func1 (a=100) at example_print.c:11
11        return array[99] * a;
(gdb) call func1
$14 = {int (int)} 0x5555550844 <func1>
(gdb) c
Continuing.
59400
[Inferior 1 (process 3531) exited normally]
```
可以看到上面修改了a的值后，虽然我正在func1中，但是我仍可以主动再调用一次func1，从而按照我的目的将func1的返回值扩大10倍。
## 利用c的jump指令
我们知道c语言支持setjmp来实现代码的跳转，最常见的是goto语句，同样的gdb也提供了jump命令，当我们调试时，要回到之前的语句上，可以直接使用jump指令，下面演示。

首先断点到func2上
```
(gdb) b func2
Breakpoint 2 at 0x55555508e0: file example_print.c, line 16.
```
此时代码在b=2上，b的值是随机的栈上的值，如下
```
(gdb) p b
$21 = 85
```
假设调试代码时，自己敲了n，则代码会到return那行语句上，如下
```
(gdb) n
17        return b * func1(a);
```
此时b的值是2，如下
```
(gdb) p b
$22 = 2
```
此时通过jump命令还能回到16行，如下
```
(gdb) jump 16
Continuing at 0x55555508e0.

Breakpoint 2, func2 (a=10) at example_print.c:16
16        int b = 2;
```
因为jump和c的setjmp一致，此时b还是2，如下
```
(gdb) p b
$20 = 2
```
但是代码当前被我修改pc寄存器回到了16行了。

通过这个方法，很方便的在一个函数中记录自己忘记记录的值，从而便于自己调试

# 总结
本文总结了gdb上的常见技巧，首先解决了所有系统中存在的源码找不到的问题，补全DWARF信息，当调试信息完整之后，就可以轻松的开始调试了。 随后也同时介绍了gdb的几个小技巧，方便自己反复调试，而不是每次忘记一些关键信息的记录，从而导致自己gdb从头来过。


gdb调试方法(6)-调试技巧

在个人的经验中，绝大部分情况下gdb调试可以单独对某个动态库的行为进行调试，这样的话就可以很方便的直接在存在异常的设备上定位问题，本文介绍如何在发行设备上，针对单个动态库进行gdb定位问题
# 测试程序
这里需要准备两个程序，一个example.c用作main调用，一个sum.c实现sum接口，代码足够精简。

sum.c的代码如下
```
int sum(int x, int y)
{
    int s = x + y;
    return s;
}
```
example.c的代码如下
```
#include <stdio.h>
#include "sum.h"

static int y = 2;

int main()
{
    int x = 1;
    printf("sum=%d \n", sum(x, y));
}
```
# 调试动态库
此时先编译so
```
gcc sum.c -shared -fPIC -o libsum.so
```
再编译二进制
```
gcc example.c -lsum -L./ -o example
```
上面编译都是不带g的。所以gdb可以直接看到libsum.so的符号状态如下
```
# export LD_LIBRARY_PATH=./
# gdb ./example
(gdb) info sharedlibrary
From                To                  Syms Read   Shared Object Library
0x0000fffff7fcd0c0  0x0000fffff7fe5468  Yes (*)     /lib/ld-linux-aarch64.so.1
0x0000fffff7fba470  0x0000fffff7fba57c  Yes (*)     ./libsum.so
0x0000fffff7e26880  0x0000fffff7f15db8  Yes         /lib/aarch64-linux-gnu/libc.so.6
                                        No          linux-vdso.so.1
```
可以看到libsum.so是无调试信息的。

这种情况下，如果调试libsum.so的sum函数内容，那么只能通过寄存器和反汇编分析。

更聪明的办法是使得其能够加载符号，最简单的办法是将libsum.so编译带上符号，如下
```
gcc sum.c -shared -fPIC -g -o libsum.so
```

如果是在debian系操作系统上原生开发，那么可以自动或者手动加载`.debug_info`段即可，或者安装对应的dbg包即可。这里无需赘述。

此时再查看二进制加载的情况如下
```
(gdb) info sharedlibrary
From                To                  Syms Read   Shared Object Library
0x0000fffff7fcd0c0  0x0000fffff7fe5468  Yes (*)     /lib/ld-linux-aarch64.so.1
0x0000fffff7fba470  0x0000fffff7fba57c  Yes         ./libsum.so
0x0000fffff7e26880  0x0000fffff7f15db8  Yes         /lib/aarch64-linux-gnu/libc.so.6
                                        No          linux-vdso.so.1
```
可以看到，此时libsum.so带上调试信息了，可以直接进行调试
```
(gdb) b sum
Breakpoint 1 at 0xfffff7fba560: file sum.c, line 3.
(gdb) r
Starting program: /root/gdb/example

Breakpoint 1, sum (x=1, y=2) at sum.c:3
3           int s = x + y;
(gdb) set x=4
(gdb) set y=6
(gdb) c
Continuing.
sum=10
[Inferior 1 (process 994034) exited normally]
```
这里libsum.so动态库的映射关系也可以在gdb中直接查看，无需进proc找，如下
```
(gdb) info proc map
process 1005668
Mapped address spaces:
          Start Addr           End Addr       Size     Offset objfile
      0xaaaaaaaaa000     0xaaaaaaaab000     0x1000        0x0 /root/gdb/example
      0xaaaaaaaba000     0xaaaaaaabb000     0x1000        0x0 /root/gdb/example
      0xaaaaaaabb000     0xaaaaaaabc000     0x1000     0x1000 /root/gdb/example
      0xfffff7e06000     0xfffff7f60000   0x15a000        0x0 /usr/lib/aarch64-linux-gnu/libc-2.31.so
      0xfffff7f60000     0xfffff7f70000    0x10000   0x15a000 /usr/lib/aarch64-linux-gnu/libc-2.31.so
      0xfffff7f70000     0xfffff7f74000     0x4000   0x15a000 /usr/lib/aarch64-linux-gnu/libc-2.31.so
      0xfffff7f74000     0xfffff7f76000     0x2000   0x15e000 /usr/lib/aarch64-linux-gnu/libc-2.31.so
      0xfffff7f76000     0xfffff7f79000     0x3000        0x0
      0xfffff7fba000     0xfffff7fbb000     0x1000        0x0 /root/gdb/libsum.so
      0xfffff7fbb000     0xfffff7fca000     0xf000     0x1000 /root/gdb/libsum.so
      0xfffff7fca000     0xfffff7fcb000     0x1000        0x0 /root/gdb/libsum.so
      0xfffff7fcb000     0xfffff7fcc000     0x1000     0x1000 /root/gdb/libsum.so
      0xfffff7fcc000     0xfffff7fed000    0x21000        0x0 /usr/lib/aarch64-linux-gnu/ld-2.31.so
      0xfffff7ff7000     0xfffff7ffb000     0x4000        0x0
      0xfffff7ffb000     0xfffff7ffc000     0x1000        0x0 [vvar]
      0xfffff7ffc000     0xfffff7ffd000     0x1000        0x0 [vdso]
      0xfffff7ffd000     0xfffff7ffe000     0x1000    0x21000 /usr/lib/aarch64-linux-gnu/ld-2.31.so
      0xfffff7ffe000     0xfffff8000000     0x2000    0x22000 /usr/lib/aarch64-linux-gnu/ld-2.31.so
      0xfffffffdf000    0x1000000000000    0x21000        0x0 [stack]
```
# 总结
可以发现，如果知道了之前关于DWARF调试信息的事情，如何针对动态库调试这件事情就变得异常简单。

在实际工作经验中，我们不可能给发行的二进制所有的代码都加上g，这是比较笨的行为，正常的处理办法是针对问题的现象初步外围分析，从而得出大致的结论，知道问题可能出现在哪些模块上，而又因为模块对应了不同的so实现，那么只需要将怀疑的so挂上符号，这样就可以放心的调试so了。这种技巧对大型工程的调试而言，简单却非常好用。




