在实际的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了。这种技巧对大型工程的调试而言，简单却非常好用。






gdb调试方法(5)-动态库调试

一个程序是否方便调试的关键在于调试信息是否完善，本文基于此简单介绍一下什么是DWARF调试信息
# 什么是DWARF
Debugging With Attributed Record Formats 是很多编译器使用的调试信息格式，他能够轻松的使得代码能够进行源码级的调试，DWARF的标准文档如下
> https://dwarfstd.org/doc/DWARF5.pdf

# DWARF包含什么
当我们编译要一个程序时，如果带g和不带g，那么就可以对比的了解到DWARF在ELF中是如何存在的，如下
```
gcc example.c -g -o example_with_dwarf
gcc example.c -o example_without_dwarf
```
此时我们对比其section即可，如下
```
readelf -S example_with_dwarf
readelf -S example_without_dwarf
```
对比情况如下

![image.png](/static/img/6a8af2f4f51e05c50ee163ae44010175.image.webp)

可以看到，dwarf实际上是新增了如下段
1. .debug_aranges
2. .debug_info
3. .debug_abbrev
4. .debug_line
5. .debug_str

这些段的内容就是提供了这个二进制可进行源码级调试的辅助内容，主要包含如下：
1. 函数名
2. 变量计算
3. 变量类型
4. 源码行
5. 源码文件路径

通过dwarfdump可以解析这些段的实际内容，如下
```
# dwarfdump -a example_with_dwarf

.debug_info

COMPILE_UNIT<header overall offset = 0x00000000>:
< 0><0x0000000b>  DW_TAG_compile_unit
                    DW_AT_producer              GNU C17 10.3.0 -mlittle-endian -mabi=lp64 -g -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection
                    DW_AT_language              DW_LANG_C99
                    DW_AT_name                  example.c
                    DW_AT_comp_dir              /root/gdb
                    DW_AT_low_pc                0x00000894
                    DW_AT_high_pc               <offset-from-lowpc>180
                    DW_AT_stmt_list             0x00000000

LOCAL_SYMBOLS:
< 1><0x0000002d>    DW_TAG_base_type
                      DW_AT_byte_size             0x00000008
                      DW_AT_encoding              DW_ATE_unsigned
                      DW_AT_name                  long unsigned int
......

.debug_line: line number info for a single cu
Source lines (from CU-DIE at .debug_info offset 0x0000000b):

            NS new statement, BB new basic block, ET end of text sequence
            PE prologue end, EB epilogue begin
            IS=val ISA number, DI=val discriminator value
<pc>        [lno,col] NS BB ET PE EB IS= DI= uri: "filepath"
0x00000894  [   9, 1] NS uri: "/root/gdb/example.c"
......

.debug_str
name at offset 0x00000000, length   13 is 'long long int'
name at offset 0x0000000e, length    4 is 'main'
name at offset 0x00000013, length   22 is 'long long unsigned int'
name at offset 0x0000002a, length   13 is 'unsigned char'
name at offset 0x00000038, length    9 is 'example.c'
name at offset 0x00000042, length   18 is 'short unsigned int'
name at offset 0x00000055, length  123 is 'GNU C17 10.3.0 -mlittle-endian -mabi=lp64 -g -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection'
name at offset 0x000000d1, length    5 is 'hello'
name at offset 0x000000d7, length    9 is 'short int'
name at offset 0x000000e1, length    9 is '/root/gdb'

.debug_aranges

COMPILE_UNIT<header overall offset = 0x00000000>:
< 0><0x0000000b>  DW_TAG_compile_unit
                    DW_AT_producer              GNU C17 10.3.0 -mlittle-endian -mabi=lp64 -g -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection
                    DW_AT_language              DW_LANG_C99
                    DW_AT_name                  example.c
                    DW_AT_comp_dir              /root/gdb
                    DW_AT_low_pc                0x00000894
                    DW_AT_high_pc               <offset-from-lowpc>180
                    DW_AT_stmt_list             0x00000000


arange starts at 0x00000894, length of 0x000000b4, cu_die_offset = 0x0000000b
arange end

.debug_frame

```
# 如何提取dwarf
在linux操作系统发行中，例如debian系列，默认提供软件包同名的ddeb，这个ddeb包含的是该程序的可调试信息，也就是dwarf信息文件。

我们以example_with_dwarf为例子，首先将其的dwarf调试信息拿出来，如下
```
objcopy --only-keep-debug example_with_dwarf example.debug
```
然后将example_with_dwarf的debug信息去掉，如下
```
objcopy --strip-debug example_with_dwarf
```
此时gdb调试example_with_dwarf是没有符号的，如下
```
# gdb ./example_with_dwarf
Reading symbols from ./example_with_dwarf...
(No debugging symbols found in ./example_with_dwarf)
(gdb) list
No symbol table is loaded.  Use the "file" command.
```
但是我们可以手动将dwarf加载进来，如下
```
(gdb) add-symbol-file example.debug
add symbol table from file "example.debug"
(y or n) y
Reading symbols from example.debug...
(gdb) list
11          memcpy(p, hello, strlen(hello) + 1);
12          free(p);
13      }
14
15      int sum(int x)
16      {
17          int s = x + y;
18          printf("sum=%d\n", s);
19          mem();
20          return s;
```
这样就使得了不带dwarf信息的二进制，能够轻易的加载分离的dwarf文件，从而支持方便的源码级的调试
# strip
通常情况下，debian package会调用strip来进行进一步裁剪，而不是如下仅仅裁剪debug info
```
strip program
objcopy --strip-debug program
```
这也就意味着strip后的程序会天然丢掉`.symtab`和`.strtab`。此时在调试操作系统时，需要注意strip的二进制会比仅删除debug info的二进制更难调试。其原因是`.symtab`和`.strtab`存放的是链接和调试用的符号表。如下解释

如果一个程序是仅删掉debug info的，那么因为`.symtab`和`.strtab`存在，所以还是能够下发断点，因为我们输入的函数名字能够正常的被gdb找到偏移，如下
```
(gdb) l
No symbol table is loaded.  Use the "file" command.
(gdb) b mem
Breakpoint 1 at 0x8a0
(gdb) r
Starting program: /root/gdb/example_with_dwarf
Breakpoint 1, 0x0000aaaaaaaaa8a0 in mem ()
```
因为dwarf提供的额外信息不存在的，所以取而代之的是代码运行时的地址，但是此时程序还是能够被调试的。

而通过strip的应用程序，如果运行gdb，那么可能无法正常通过名字下发断点，如下
```
# strip  example_with_dwarf
# gdb ./example_with_dwarf
(gdb) l
No symbol table is loaded.  Use the "file" command.
(gdb) b main
Function "main" not defined.
Breakpoint 1 (main) pending.
(gdb) b mem
Function "mem" not defined.
Breakpoint 2 (mem) pending.
(gdb) r
Starting program: /root/gdb/example_with_dwarf
sum=3
[Inferior 1 (process 756218) exited normally]
```
可以看到，我们在gdb下发的是函数名，但是因为缺少了`.symtab`和`.strtab`，自然就找不到对应名字的函数地址了。

# 如何找到strip后的二进制入口
根据上面说的，如果一个程序strip之后无法通过函数名找到地址了，那么怎么定位和调试呢。  其实可以通过计算来找到函数的入口，如下   
当程序strip之后，我们没办法给main下断点
```
(gdb) b main
Function "main" not defined.
```
但是程序总有入口的，这个入口在elf头的entry上，在gdb中，可以读取真实的偏移后的entry，需要先加载一次程序，如下
```
(gdb) r
Starting program: /root/gdb/example
sum=3
[Inferior 1 (process 830429) exited normally]
(gdb) info files
Symbols from "/root/gdb/example".
Local exec file:
        `/root/gdb/example', file type elf64-littleaarch64.
        Entry point: 0xaaaaaaaaa780
```
可以看到此程序的入口是0xaaaaaaaaa780，所以对这个地址下断点即可
```
(gdb) b *0xaaaaaaaaa780
Breakpoint 1 at 0xaaaaaaaaa780
(gdb) r
Starting program: /root/gdb/example

Breakpoint 1, 0x0000aaaaaaaaa780 in ?? ()
```
这是实际的函数入口，值得注意的是，这并不是main函数，而是`_start`函数，接下来就可以做一下黑客操作了。

# 如何调试一个不带符号的程序
根据上面说的，在操作系统中，大量的程序是被strip过的，这种情况下，我们无法简单的调试他，因为函数名就对应不了地址，通过人来计算很难实现。

但是通常说不带符号的程序，应该是编译没有带g标志的程序，同时也没有被strip的程序。

那么这种程序，如何调试呢？

这种情况其实很简单，根据之前的文章我们知道，程序是否易调试的主要原因是dwarf的加载，那么这个问题就是如果没有dwarf信息的加载，如何自行通过寄存器推理计算来调试某个函数。下面通过一个简单的sum来实践一下

函数如下
```
int sum(int x)
{
    int s = x + y;
    printf("sum=%d\n", s);
    return s;
}
```
那么如果在没有dwarf信息帮助的前提下，获取x，y，s三个值呢。 那么就是通过看寄存器和反汇编完成，我们可以对sum函数打下断点，然后反汇编查看，如下
```
(gdb) b sum
Breakpoint 1 at 0x8f4
(gdb) r
Starting program: /root/gdb/example

Breakpoint 1, 0x0000aaaaaaaaa8f4 in sum ()
(gdb) disassemble
Dump of assembler code for function sum:
   0x0000aaaaaaaaa8e0 <+0>:     stp     x29, x30, [sp, #-48]!
   0x0000aaaaaaaaa8e4 <+4>:     mov     x29, sp
   0x0000aaaaaaaaa8e8 <+8>:     str     w0, [sp, #28]
   0x0000aaaaaaaaa8ec <+12>:    adrp    x0, 0xaaaaaaabb000
   0x0000aaaaaaaaa8f0 <+16>:    add     x0, x0, #0x18
=> 0x0000aaaaaaaaa8f4 <+20>:    ldr     w0, [x0]
   0x0000aaaaaaaaa8f8 <+24>:    ldr     w1, [sp, #28]
   0x0000aaaaaaaaa8fc <+28>:    add     w0, w1, w0
   0x0000aaaaaaaaa900 <+32>:    str     w0, [sp, #44]
   0x0000aaaaaaaaa904 <+36>:    ldr     w1, [sp, #44]
   0x0000aaaaaaaaa908 <+40>:    adrp    x0, 0xaaaaaaaaa000
   0x0000aaaaaaaaa90c <+44>:    add     x0, x0, #0x9e8
   0x0000aaaaaaaaa910 <+48>:    bl      0xaaaaaaaaa770 <printf@plt>
   0x0000aaaaaaaaa914 <+52>:    ldr     w0, [sp, #44]
   0x0000aaaaaaaaa918 <+56>:    ldp     x29, x30, [sp], #48
   0x0000aaaaaaaaa91c <+60>:    ret
End of assembler dump.
```
可以看到，根据汇编对照代码分析，y的值应该在0xaaaaaaabb018 所以直接读取验证即可
```
0xaaaaaaabb018 <y>:     0x00000002
```
而x的值应该在sp+28，读取验证即可
```
(gdb) x/wx $sp+28
0xfffffffff30c: 0x00000001
```
此时s的值被存放到sp+44，所以我们先调整栈帧，然后打印即可
```
(gdb) b *0x0000aaaaaaaaa904
Breakpoint 2 at 0xaaaaaaaaa904
(gdb) c
Continuing.

Breakpoint 2, 0x0000aaaaaaaaa904 in sum ()
(gdb) x $sp+44
0xfffffffff31c: 0x00000003
```
至此，也就完成了一个没有符号的前提下，简单调试一个函数。其本质还是反汇编理解代码并修改内存而已。相比于没有dwarf信息的程序调试而言，更加枯燥无味。
# 总结
本文基于调试信息进行了一个简单的介绍，从而能够更清晰的理解gdb调试的技巧。如果一个程序没有dwarf信息，那么调试它则需要通过分析栈区，分析汇编从而理解，这种理解通常只能是片段逻辑分析。  
而如果一个程序有dwarf信息，那么使用gdb调试就会如鱼得水，非常方便。能够进行整体代码行为的分析。  
如果一个程序被strip后，按照个人经验，不建议强行分析，即使计算了内存地址，也有可能无法访问，投入产出不成正比。

gdb调试方法(4)-调试信息

从《gdb调试方法(2)-ptrace》可以看到，ptrace会频繁的下发PTRACE_GETREGS 和 PTRACE_SETREGS ,通过修改pc寄存器，从而使得进程能够被gdb接管，在trace处运行gdb的相关命令。

本文基于简单的程序，使用gdb完成简单的调试工作

# 调试什么
根据ptrace的理解，我们可以大概总结gdb能够获取哪些内容
1. 当前寄存器
2. DWARF调试信息
3. 函数调用栈
4. 变量
5. 函数当前栈
6. 内存内容
7. 线程状态
8. 函数汇编指令

# 示例代码
为了简单的实现gdb的调试，这里提供一个简易的示例代码如下
```
#include <stdio.h>

static char hello[] = "hello";
int y = 2;

void mem()
{
    void *p = malloc(sizeof(char)*10);
    memcpy(p, hello, strlen(hello) + 1);
    free(p);
}

int sum(int x)
{
    int s = x + y;
    printf("sum=%d\n", s);
    return s;
}

int main()
{
    int x = 1;
    sum(x);
    mem();
}
```
# 实践
为了编译可调试并带有DWARF调试信息，只需要编译时增加g选项即可
```
gcc example.c -g -o example
```
然后gdb直接调试即可
```
# gdb ./example
```
## 设置断点
```
(gdb) b sum
Breakpoint 1 at 0x780: file example.c, line 8.
(gdb) r
Starting program: /root/gdb/example

Breakpoint 1, sum (x=1) at example.c:8
8           int s = x + y;
```
## 查看寄存器
因为sum的形参是x，所以我们可以看到x0的值就是1 
```
(gdb) i r
x0             0x1                 1
x1             0xfffffffff498      281474976707736
x2             0xfffffffff4a8      281474976707752
x3             0xaaaaaaaaa7b4      187649984473012
x4             0x0                 0
x5             0xc56a615efa85d69   889080589597564265
x6             0xfffff7f87ad8      281474842000088
x7             0x4040100000000000  4629718009122914304
x8             0xffffffffffffffff  -1
x9             0xffff              65535
x10            0x800000008000      140737488388096
x11            0x0                 0
x12            0xfffff7e1be48      281474840510024
x13            0x0                 0
x14            0x0                 0
x15            0x6fffff47          1879048007
x16            0xaaaaaaabafa0      187649984540576
x17            0xfffff7e38c68      281474840628328
x18            0x73516240          1934713408
x19            0xaaaaaaaaa7d8      187649984473048
x20            0x0                 0
x21            0xaaaaaaaaa660      187649984472672
x22            0x0                 0
x23            0x0                 0
x24            0x0                 0
x25            0x0                 0
x26            0x0                 0
x27            0x0                 0
x28            0x0                 0
x29            0xfffffffff2f0      281474976707312
x30            0xaaaaaaaaa7cc      187649984473036
sp             0xfffffffff2f0      0xfffffffff2f0
pc             0xaaaaaaaaa780      0xaaaaaaaaa780 <sum+12>
cpsr           0x60000000          [ EL=0 C Z ]
fpsr           0x0                 0
fpcr           0x0                 0
```
## 查看堆栈
因为能够获得寄存器，所以可以从x30和x29推算堆栈，然后结合DWARF的信息可以打印如下。
```
(gdb) bt
#0  sum (x=1) at example.c:8
#1  0x0000aaaaaaaaa7cc in main () at example.c:16
```
## 查看源码
因为代码存在DWARF信息，所以能够借助DWARF信息查看代码行，如下
```
(gdb) l
13      int main()
14      {
15          int x = 1;
16          sum(x);
17      }
18
```
## 查看变量
DWARF提供了局部变量的偏移值，以及全局变量和静态的固定加载地址。所以借助DAWRF的信息，可以在gdb中查看变量
```
(gdb) p x
$3 = 1
(gdb) p y
$4 = 2
(gdb) p hello
$5 = "hello"
(gdb) p s
$6 = 0
```
## 查看内存
因为DWARF会帮我们计算好p的值，所以我们可以轻松的通过x打印内存，如下
```
(gdb) u 12
mem () at example.c:12
12          free(p);
(gdb) x/10c p
0xaaaaaaabc6b0: 104 'h' 101 'e' 108 'l' 108 'l' 111 'o' 0 '\000'        0 '\000'        0 '\000'
0xaaaaaaabc6b8: 0 '\000'        0 '\000'
```
同样的，也可以使用dump直接打印区域的内存，只要我们自行计算好变量起始地址和结束即可。  
首先我们对mem函数反汇编
```
(gdb) disassemble/m
Dump of assembler code for function mem:
9       {
   0x0000aaaaaaaaa894 <+0>:     stp     x29, x30, [sp, #-32]!
   0x0000aaaaaaaaa898 <+4>:     mov     x29, sp

10          void *p = malloc(sizeof(char)*10);
=> 0x0000aaaaaaaaa89c <+8>:     mov     x0, #0xa                        // #10
   0x0000aaaaaaaaa8a0 <+12>:    bl      0xaaaaaaaaa720 <malloc@plt>
   0x0000aaaaaaaaa8a4 <+16>:    str     x0, [sp, #24]

11          memcpy(p, hello, strlen(hello) + 1);
   0x0000aaaaaaaaa8a8 <+20>:    adrp    x0, 0xaaaaaaabb000
   0x0000aaaaaaaaa8ac <+24>:    add     x0, x0, #0x10
   0x0000aaaaaaaaa8b0 <+28>:    bl      0xaaaaaaaaa700 <strlen@plt>
   0x0000aaaaaaaaa8b4 <+32>:    add     x0, x0, #0x1
   0x0000aaaaaaaaa8b8 <+36>:    mov     x2, x0
   0x0000aaaaaaaaa8bc <+40>:    adrp    x0, 0xaaaaaaabb000
   0x0000aaaaaaaaa8c0 <+44>:    add     x1, x0, #0x10
   0x0000aaaaaaaaa8c4 <+48>:    ldr     x0, [sp, #24]
   0x0000aaaaaaaaa8c8 <+52>:    bl      0xaaaaaaaaa6f0 <memcpy@plt>

12          free(p);
   0x0000aaaaaaaaa8cc <+56>:    ldr     x0, [sp, #24]
   0x0000aaaaaaaaa8d0 <+60>:    bl      0xaaaaaaaaa760 <free@plt>

13      }
   0x0000aaaaaaaaa8d4 <+64>:    nop
   0x0000aaaaaaaaa8d8 <+68>:    ldp     x29, x30, [sp], #32
   0x0000aaaaaaaaa8dc <+72>:    ret

End of assembler dump.
```
如果我们想取出`void* p`的内存，可以看到sp+24存放了malloc的地址，而传入malloc的参数是0xa，如下
```
10          void *p = malloc(sizeof(char)*10);
=> 0x0000aaaaaaaaa89c <+8>:     mov     x0, #0xa                        // #10
   0x0000aaaaaaaaa8a0 <+12>:    bl      0xaaaaaaaaa720 <malloc@plt>
   0x0000aaaaaaaaa8a4 <+16>:    str     x0, [sp, #24]
```
然后解析malloc返回地址，如下
```
(gdb) x/gx $sp + 24
0xfffffffff2e8: 0x0000aaaaaaabc6b0
```
所以可以直接将其dump出来，如下
```
(gdb) u 12
mem () at example.c:12
12          free(p);
(gdb) dump binary memory test.bin 0x0000aaaaaaabc6b0 0x0000aaaaaaabc6b0+10
```
此时可以看到test.bin就是我想要查看的内存内容 hello
```
# hexdump -C test.bin
00000000  68 65 6c 6c 6f 00 00 00  00 00                    |hello.....|
0000000a
```
## 打印类型
打印类型也是非常常用的命令，借助DWARF可以帮我们默认解析好变量的类型，所以可以直接打印，如下
```
(gdb) ptype y
type = int
```
## 打印线程
多线程程序调试时，可以通过threads来切换线程，并单独控制某个线程，打印线程的命令如下
```
(gdb) i threads
  Id   Target Id                Frame
* 1    process 392716 "example" mem () at example.c:12
```
# 总结
到这里，gdb的基本简单调试的方法已经说明了，可以发现，gdb调试绝大部分情况下还是依赖DWARF调试信息，如果有这个信息，那么调试会变得非常简单，如果没有这个信息，那么就得人为的计算，如果不辅助一下插桩的技巧，或者标记点，那么调试计算会变得很麻烦，但是总而言之，调试的时候，尽可能得需要保证二进制包含DWARF调试信息。

