在系统开发过程中，部署在设备的版本通常是release版本，所以一般是不带调试信息的，当问题出现时，我们如何排查呢？ 实际上在linux中提供了coredump的功能，当程序出现崩溃时，会给我们转储core文件，只要我们拿到core文件，就相当于拿到了问题现场，接下来就是利用gdb来分析问题了。
# core文件在哪里
对于linux系统，我们首先要查看systemd-coredump是否安装，如果systemd-coredump不安装，那么core文件是存放在默认的内核位置，内核会将其写成core，故core文件会存在启动用户的根目录，假设当前启动用户是kylin，那么core文件就在如下
```
# file /home/kylin/core
/home/kylin/core: ELF 64-bit LSB core file, ARM aarch64, version 1 (SYSV), SVR4-style, from '/usr/bin/ukui-panel', real uid: 1000, effective uid: 1000, real gid: 1000, effective gid: 1000, execfn: '/usr/bin/ukui-panel', platform: 'aarch64'
```
同样的我们可以通过内核提供的proc文件查看core的位置，如下
```
# cat /proc/sys/kernel/core_pattern
core
```
如果我们安装了systemd-coredump包，那么core文件就由systemd接管，实际位置如下
```
# cat /proc/sys/kernel/core_pattern
|/lib/systemd/systemd-coredump %P %u %g %s %t 9223372036854775808 %h
```
此时core文件的位置在`/var/lib/systemd/coredump/`
# 实战
当系统内有二进制出现崩溃的时候，core文件会生成，接下来以一个实际的例子来介绍如何调试core文件。这个经验对于调试操作系统而言，非常之有用。

我手动创造了一个崩溃示例，此时可以发现coredump目录下存在如下文件
```
core.kylin-vpn.1000.930a6eece73248149cd465ddbe02d695.17632.1757114505000000000000.lz4
```
从这个信息可以知道，是kylin-vpn出现了崩溃，我们应该调试kylin-vpn，首先需要解压这个lz4文件，如下
```
# lz4 core.kylin-vpn.1000.930a6eece73248149cd465ddbe02d695.17632.1757114505000000000000.lz4
# file core.kylin-vpn.1000.930a6eece73248149cd465ddbe02d695.17632.1757114505000000000000
core.kylin-vpn.1000.930a6eece73248149cd465ddbe02d695.17632.1757114505000000000000: ELF 64-bit LSB core file, ARM aarch64, version 1 (SYSV), SVR4-style, from '/usr/bin/kylin-vpn', real uid: 1000, effective uid: 1000, real gid: 1000, effective gid: 1000, execfn: '/usr/bin/kylin-vpn', platform: 'aarch64'
```
此时假设我们直接gdb调试，看看什么效果
```
# gdb -c core.kylin-vpn.1000.930a6eece73248149cd465ddbe02d695.17632.1757114505000000000000 /usr/bin/kylin-vpn
Reading symbols from /usr/bin/kylin-vpn...
(No debugging symbols found in /usr/bin/kylin-vpn)
Core was generated by `/usr/bin/kylin-vpn'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000007fa009f5a0 in QDBusMetaType::typeToSignature(int) () from /lib/aarch64-linux-gnu/libQt5DBus.so.5
```
我把关键信息贴在上面，可以看到代码出现了段错误，出现在libQt5DBus.so.5的QDBusMetaType::typeToSignature(int)函数上。

此时尝试反汇编QDBusMetaType::typeToSignature函数，发现并不能正常反汇编，如下
```
(gdb) disassemble QDBusMetaType::typeToSignature
No symbol "QDBusMetaType" in current context.
```
这是什么原因呢？其实在《gdb调试方法(4)-调试信息》里面提到过，这个动态库是发行版的动态库，自然被strip过，而strip过的动态库是找不到对应符号的。所以这种情况很正常，不要慌张。接下来逐步调试问题。

虽然我们知道了问题出现在`QDBusMetaType::typeToSignature`，但是我们还是要一步一步判断和调试问题。首先，我们留意到kylin-vpn并没有符号，所以先打上对应符号，如下
```
# dpkg -S /usr/bin/kylin-vpn
kylin-nm: /usr/bin/kylin-vpn
# dpkg -i kylin-nm-dbgsym_3.20.1.7-0k0.1tablet8.egf0.6_arm64.ddeb
```
上述安装实际上就是把kylin-vpn的符号打进系统，有gdb根据build-id加载对应的debuginfo，ddeb的内容如下
```
# dpkg -L kylin-nm-dbgsym
/.
/usr
/usr/lib
/usr/lib/debug
/usr/lib/debug/.build-id
/usr/lib/debug/.build-id/0f
/usr/lib/debug/.build-id/0f/470de270e27775339fd5c2cc71f2f5610d10c2.debug
/usr/lib/debug/.build-id/0f/afcd08ad5eb832b1efb97a785767c90458ef82.debug
/usr/lib/debug/.build-id/1f
/usr/lib/debug/.build-id/1f/42ddf71452964a5f507f24d4db18507046b9c7.debug
/usr/lib/debug/.build-id/41
/usr/lib/debug/.build-id/41/36dbbc90afa8a433f445f7bb964f9beea34fe2.debug
/usr/lib/debug/.build-id/63
/usr/lib/debug/.build-id/63/a064e1ef52b9ab4039a21bf4093082f844ac9f.debug
/usr/lib/debug/.build-id/83
/usr/lib/debug/.build-id/83/90208727fef2f884cf665bf868d46469056e3e.debug
/usr/lib/debug/.build-id/da
/usr/lib/debug/.build-id/da/f42bf2c9e3f18cf6716cdc49ad1811e130ee46.debug
```
此时重新gdb挂载，可以看到二进制的符号打进去了，如下
```
Reading symbols from /usr/bin/kylin-vpn...
Reading symbols from /usr/lib/debug/.build-id/0f/afcd08ad5eb832b1efb97a785767c90458ef82.debug...
```
但是，我们还是无法看到代码行数，如下
```
(gdb) l
66      main.cpp: 没有那个文件或目录.
```
所以还需要把对应的代码放进来，如下
```
scp -r source/src-vpn dest@kylin:~/
```
然后用gdb去加载自己需要的源码片段，如下
```
# gdb -c core.kylin-vpn.1000.930a6eece73248149cd465ddbe02d695.17632.1757114505000000000000 /usr/bin/kylin-vpn -d ~/src-vpn/
```
此时gdb就能正常加载所有kylin-vpn的代码了，如下
```
(gdb) l
66              break;
67          case QtCriticalMsg:
68              fprintf(log_file? log_file: stderr, "Critical: %s: %s (%s:%u, %s)\n", currentDateTime.constData(), localMsg.constData(), file, context.line, function);
69              break;
70          case QtFatalMsg:
71              fprintf(log_file? log_file: stderr, "Fatal: %s: %s (%s:%u, %s)\n", currentDateTime.constData(), localMsg.constData(), file, context.line, function);
72              break;
73          }
74
75          if (log_file)
```
我们可以基于kylin-vpn进行源码分析了。

但是，我们的问题刚刚发现实际上是在QDBusMetaType::typeToSignature函数，此时我们再反汇编一下，如下
```
(gdb) disassemble QDBusMetaType::typeToSignature
There is no field named typeToSignature
```
可以看到，因为我们加载了二进制的源码和符号，但是出问题的地方并不是我们kylin-vpn这个二进制，所以这个错误变了，从No symbol 到 no field named 。也就是说，我们需要针对typeToSignature函数来进一步调试。

根据这个信息，我们知道出问题的动态库是libQt5Dbus.so.5
```
#0  0x0000007fa009f5a0 in QDBusMetaType::typeToSignature(int) () from /lib/aarch64-linux-gnu/libQt5DBus.so.5
```
此时我们安装对应的ddeb即可，如下
```
# dpkg -S /usr/lib/aarch64-linux-gnu/libQt5DBus.so.5
libqt5dbus5:arm64: /usr/lib/aarch64-linux-gnu/libQt5DBus.so.5
# dpkg -i libqt5dbus5-dbgsym_5.12.8+dfsg_arm64.ddeb
```
这里有个小的注意点，那就是默认情况下，一些系统例如麒麟是user-merged，也就是将lib目录迁移到/usr/lib下，所以我们dpkg -S找包的时候需要追加/usr目录。

关于user merged 不是文章重点，有兴趣可以查看如下文章
> https://wiki.gentoo.org/wiki/Merge-usr

回到问题，我们再gdb调试看一下什么情况了
```
# gdb -c core.kylin-vpn.1000.930a6eece73248149cd465ddbe02d695.17632.1757114505000000000000 /usr/bin/kylin-vpn -d src-vpn/
Core was generated by `/usr/bin/kylin-vpn'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  QDBusMetaType::typeToSignature (type=8) at qdbusmetatype.cpp:462
462     qdbusmetatype.cpp: 没有那个文件或目录.
[Current thread is 1 (Thread 0x7f812179b0 (LWP 17851))]
(gdb) list qdbusmetatype.cpp:1
1       in qdbusmetatype.cpp
```
可以看到，此时libQt5DBus.so.5的符号已经打上了，已经尝试在找DWARF的源码位置了，源码是qdbusmetatype.cpp，但是源码找不到。

所以反汇编是对应不到源码的，如下
```
(gdb) disassemble /m QDBusMetaType::typeToSignature
Dump of assembler code for function QDBusMetaType::typeToSignature(int):
152     in qdbusmetatype.cpp
   0x0000007fa009f4f4 <+420>:   add     x25, x22, #0x20
   0x0000007fa009f4f8 <+424>:   ldarb   w0, [x25]
   0x0000007fa009f4fc <+428>:   tbz     w0, #0, 0x7fa009f5b4 <QDBusMetaType::typeToSignature(int)+612>
   0x0000007fa009f500 <+432>:   add     x19, x19, #0x20
   0x0000007fa009f504 <+436>:   add     x23, x19, #0x28

153     in qdbusmetatype.cpp
154     in qdbusmetatype.cpp
155     in qdbusmetatype.cpp
156     in qdbusmetatype.cpp
157     in qdbusmetatype.cpp
158     in qdbusmetatype.cpp
159     in qdbusmetatype.cpp
160     in qdbusmetatype.cpp
```

所以我们需要从代码库将此文件找到，scp到机器上，如下
```
scp src/dbus/qdbusmetatype.cpp  root@91:~/core/
```
如果在gdb的运行目录，则无需手动加载，如果不在，就需要手动加载，手动加载的方式如下
```
(gdb) directory .
Source directories searched: ~/core:~/core/src-vpn:$cdir:$cwd
```
此时可以看到源码了
```
(gdb)  list qdbusmetatype.cpp:1
1       /****************************************************************************
2       **
3       ** Copyright (C) 2016 The Qt Company Ltd.
4       ** Contact: https://www.qt.io/licensing/
5       **
6       ** This file is part of the QtDBus module of the Qt Toolkit.
7       **
8       ** $QT_BEGIN_LICENSE:LGPL$
9       ** Commercial License Usage
10      ** Licensees holding valid commercial Qt licenses may use this file in
```
然后再反汇编就找得到源码了，我们找到出问题的地方，如下
```
462             if (type >= ct->size())
   0x0000007fa009f51c <+460>:   ldr     x24, [x23]
=> 0x0000007fa009f5a0 <+592>:   ldr     x24, [x23]

463                 return 0;           // type not registered with us
```
可以看到这句汇编，将x23的内容加载到x24寄存器中。其源码逻辑是 `type >= ct->size()`我们根据上下文分析一下先
```
=> 0x0000007fa009f5a0 <+592>:   ldr     x24, [x23]
   0x0000007fa009f5a4 <+596>:   ldr     w0, [x24, #4]
   0x0000007fa009f5a8 <+600>:   cmp     w20, w0
```
可以看到，这里w20是type的值，w0是ct->size()的值，为了取ct->size()，需要先取出ct的指针，也就是`ldr     x24, [x23]`，然后用ct的指针取size位置的值到w0，也就是偏移4的位置`ldr     w0, [x24, #4]`。

这里如果出现段错误，那么就是x23的值取不到了，在linux系统中，默认将0地址作为不可访问段错误地址，用来有效提醒用户。所以猜测x23的值是0。验证一下
```
(gdb) p $x23
$2 = 0
(gdb) p $w20
$1 = 8
(gdb) p type
$3 = 8
```
可以看到，因为ct已经是nullptr了，所以取size自然就段错误了，我们翻阅一下qdbusmetatype.cpp找一下ct的初始化，如下
```
    Q_GLOBAL_STATIC(QVector<QDBusCustomTypeInfo>, customTypes)
    QVector<QDBusCustomTypeInfo> *ct = customTypes();
```
可以看到，customTypes实际上是静态全局变量vector，为何会被置空为nullptr呢？

其实问题很清晰明了了，kylin-vpn会调用dbus从而调用qtbase，在系统关机过程中，qt会析构，而静态变量的析构顺序和链接顺序有关(可参考文章《使用ASAN定位全局变量构造顺序问题》)，也就是说kylin-vpn析构之前，qt的这个qdbusmetatype.o已经析构了，所以kylin-vpn在访问dbus从而访问了qdbusmetatype.o的静态变量，从而出现了空指针引用的问题。

处理这个问题就是从操作系统设计上考虑，在关机时注意多个进程之间的时序问题，从而避免不必要的coredump产生。

到这里通过gdb分析core的一次实战已经完成了。几乎所有遇到的coredump文件，通过上述这套方法都能快准狠的找出问题。

# 使用pwndbg
上面基于gdb已经能够完成调试目的了，这里再补充一下pwndbg是如何迅速找到问题的。

首先启用pwndbg，如下
```
# cat ~/.gdbinit
source ~/pwndbg/gdbinit.py
```
然后gdb加载core文件，此时pwndbg会在崩溃出打印context，如下
```
 ► 0x7fa009f5a0 <QDBusMetaType::typeToSignature(int)+592>    ldr    x24, [x23]        <Cannot dereference [0]>
   0x7fa009f5a4 <QDBusMetaType::typeToSignature(int)+596>    ldr    w0, [x24, #4]
```
```
 ► 462         if (type >= ct->size())
   463             return 0;           // type not registered with us
```
```
 X23  0
```
原因之间展示在眼前了，无需分析，pwndbg直接就告诉你问题是`Cannot dereference [0]`。迅速定位到问题。

# 总结
本文分享了非常常用的调试core的万能方法，通过此方法，后面遇到任何coredump的问题都能迎刃而解。如果使用gdb去分析和计算还是比较累，可以尝试在设备上部署pwndbg，这样存在的问题pwndbg就直接在加载时告诉你答案了，无需分析。


gdb调试方法(10)-coredump

通常调试问题的时候，经常会遇到链表，而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从头来过。
