在个人的经验中，绝大部分情况下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调试信息。



gdb调试方法(3)-简单调试

gdb默认是通过ptrace系统调用实现功能，本文简单了解ptrace。
# ptrace
ptrace的系统调用
```
/* kernel/ptrace.c */
#define __NR_ptrace 117
__SYSCALL(__NR_ptrace, sys_ptrace)
```
在使用ptrace时需要包含`/sys/ptrace.h` ，调用ptrace系统调用的时候，需要根据不同的request来发送请求，request的种类如下
```
enum __ptrace_request
{
  /* Indicate that the process making this request should be traced.
     All signals received by this process can be intercepted by its
     parent, and its parent can use the other `ptrace' requests.  */
  PTRACE_TRACEME = 0,
#define PT_TRACE_ME PTRACE_TRACEME

  /* Return the word in the process's text space at address ADDR.  */
  PTRACE_PEEKTEXT = 1,
#define PT_READ_I PTRACE_PEEKTEXT

  /* Return the word in the process's data space at address ADDR.  */
  PTRACE_PEEKDATA = 2,
#define PT_READ_D PTRACE_PEEKDATA

  /* Return the word in the process's user area at offset ADDR.  */
  PTRACE_PEEKUSER = 3,
#define PT_READ_U PTRACE_PEEKUSER

  /* Write the word DATA into the process's text space at address ADDR.  */
  PTRACE_POKETEXT = 4,
#define PT_WRITE_I PTRACE_POKETEXT

  /* Write the word DATA into the process's data space at address ADDR.  */
  PTRACE_POKEDATA = 5,
#define PT_WRITE_D PTRACE_POKEDATA

  /* Write the word DATA into the process's user area at offset ADDR.  */
  PTRACE_POKEUSER = 6,
#define PT_WRITE_U PTRACE_POKEUSER

  /* Continue the process.  */
  PTRACE_CONT = 7,
#define PT_CONTINUE PTRACE_CONT

  /* Kill the process.  */
  PTRACE_KILL = 8,
#define PT_KILL PTRACE_KILL

  /* Single step the process.  */
  PTRACE_SINGLESTEP = 9,
#define PT_STEP PTRACE_SINGLESTEP

  /* Get all general purpose registers used by a processes.  */
  PTRACE_GETREGS = 12,
#define PT_GETREGS PTRACE_GETREGS

  /* Set all general purpose registers used by a processes.  */
  PTRACE_SETREGS = 13,
#define PT_SETREGS PTRACE_SETREGS
  /* Get all floating point registers used by a processes.  */
  PTRACE_GETFPREGS = 14,
#define PT_GETFPREGS PTRACE_GETFPREGS

  /* Set all floating point registers used by a processes.  */
  PTRACE_SETFPREGS = 15,
#define PT_SETFPREGS PTRACE_SETFPREGS

  /* Attach to a process that is already running. */
  PTRACE_ATTACH = 16,
#define PT_ATTACH PTRACE_ATTACH

  /* Detach from a process attached to with PTRACE_ATTACH.  */
  PTRACE_DETACH = 17,
#define PT_DETACH PTRACE_DETACH

  /* Get all extended floating point registers used by a processes.  */
  PTRACE_GETFPXREGS = 18,
#define PT_GETFPXREGS PTRACE_GETFPXREGS

  /* Set all extended floating point registers used by a processes.  */
  PTRACE_SETFPXREGS = 19,
#define PT_SETFPXREGS PTRACE_SETFPXREGS

  /* Continue and stop at the next entry to or return from syscall.  */
  PTRACE_SYSCALL = 24,
#define PT_SYSCALL PTRACE_SYSCALL

  /* Get a TLS entry in the GDT.  */
  PTRACE_GET_THREAD_AREA = 25,
#define PT_GET_THREAD_AREA PTRACE_GET_THREAD_AREA

  /* Change a TLS entry in the GDT.  */
  PTRACE_SET_THREAD_AREA = 26,
#define PT_SET_THREAD_AREA PTRACE_SET_THREAD_AREA

  /* Continue and stop at the next syscall, it will not be executed.  */
  PTRACE_SYSEMU = 31,
#define PT_SYSEMU PTRACE_SYSEMU

  /* Single step the process, the next syscall will not be executed.  */
  PTRACE_SYSEMU_SINGLESTEP = 32,
#define PT_SYSEMU_SINGLESTEP PTRACE_SYSEMU_SINGLESTEP

  /* Execute process until next taken branch.  */
  PTRACE_SINGLEBLOCK = 33,
#define PT_STEPBLOCK PTRACE_SINGLEBLOCK

  /* Set ptrace filter options.  */
  PTRACE_SETOPTIONS = 0x4200,
#define PT_SETOPTIONS PTRACE_SETOPTIONS
  /* Get last ptrace message.  */
  PTRACE_GETEVENTMSG = 0x4201,
#define PT_GETEVENTMSG PTRACE_GETEVENTMSG

  /* Get siginfo for process.  */
  PTRACE_GETSIGINFO = 0x4202,
#define PT_GETSIGINFO PTRACE_GETSIGINFO

  /* Set new siginfo for process.  */
  PTRACE_SETSIGINFO = 0x4203,
#define PT_SETSIGINFO PTRACE_SETSIGINFO

  /* Get register content.  */
  PTRACE_GETREGSET = 0x4204,
#define PTRACE_GETREGSET PTRACE_GETREGSET

  /* Set register content.  */
  PTRACE_SETREGSET = 0x4205,
#define PTRACE_SETREGSET PTRACE_SETREGSET

  /* Like PTRACE_ATTACH, but do not force tracee to trap and do not affect
     signal or group stop state.  */
  PTRACE_SEIZE = 0x4206,
#define PTRACE_SEIZE PTRACE_SEIZE

  /* Trap seized tracee.  */
  PTRACE_INTERRUPT = 0x4207,
#define PTRACE_INTERRUPT PTRACE_INTERRUPT

  /* Wait for next group event.  */
  PTRACE_LISTEN = 0x4208,
#define PTRACE_LISTEN PTRACE_LISTEN

  /* Retrieve siginfo_t structures without removing signals from a queue.  */
  PTRACE_PEEKSIGINFO = 0x4209,
#define PTRACE_PEEKSIGINFO PTRACE_PEEKSIGINFO

  /* Get the mask of blocked signals.  */
  PTRACE_GETSIGMASK = 0x420a,
#define PTRACE_GETSIGMASK PTRACE_GETSIGMASK

  /* Change the mask of blocked signals.  */
  PTRACE_SETSIGMASK = 0x420b,
#define PTRACE_SETSIGMASK PTRACE_SETSIGMASK

  /* Get seccomp BPF filters.  */
  PTRACE_SECCOMP_GET_FILTER = 0x420c,
#define PTRACE_SECCOMP_GET_FILTER PTRACE_SECCOMP_GET_FILTER

  /* Get seccomp BPF filter metadata.  */
  PTRACE_SECCOMP_GET_METADATA = 0x420d,
#define PTRACE_SECCOMP_GET_METADATA PTRACE_SECCOMP_GET_METADATA

  /* Get information about system call.  */
  PTRACE_GET_SYSCALL_INFO = 0x420e,
#define PTRACE_GET_SYSCALL_INFO PTRACE_GET_SYSCALL_INFO

  /* Get rseq configuration information.  */
  PTRACE_GET_RSEQ_CONFIGURATION = 0x420f
#define PTRACE_GET_RSEQ_CONFIGURATION PTRACE_GET_RSEQ_CONFIGURATION
};
```
不同的ptrace请求上面其实存在简要的注释，如果需要详细了解，可以man-page链接查看
> https://man7.org/linux/man-pages/man2/ptrace.2.html

# gdb如何调用ptrace
针对gdb，我们可以准备一个简单的hello world程序，然后使用gdb进行调试。查看一个简单的hello world是如何进行ptrace调用的。简单的程序如下
```
int main() { printf("hello \n");}
```
因为ptrace是系统调用，可以直接使用`perf trace -e`抓取，如下
```
gcc test.c -o test
perf trace -e ptrace -p $(pidof gdb)
```
运行日志如下
```
     0.000 ( 0.007 ms): gdb/6228 ptrace(request: 12, pid: 6249, data: 140731401603456)                 = 0
     0.010 ( 0.001 ms): gdb/6228 ptrace(request: 16898, pid: 6249, data: 140731401607008)              = 0
     0.049 ( 0.002 ms): gdb/6228 ptrace(request: 7, pid: 6249, addr: 0x1)                              = 0
     0.836 ( 0.002 ms): gdb/6228 ptrace(request: 12, pid: 6249, data: 140731401603456)                 = 0
     0.840 ( 0.001 ms): gdb/6228 ptrace(request: 16898, pid: 6249, data: 140731401607008)              = 0
     0.854 ( 0.001 ms): gdb/6228 ptrace(request: 16896, pid: 6249, data: 1048639)                      = 0
     0.886 ( 0.001 ms): gdb/6228 ptrace(request: 3, pid: 6249, addr: 0x88, data: 140731401607416)      = 0
     0.888 ( 0.001 ms): gdb/6228 ptrace(request: 3, pid: 6249, addr: 0xb8, data: 140731401607416)      = 0
     0.901 ( 0.001 ms): gdb/6228 ptrace(request: 12, pid: 6249, data: 140731401604736)                 = 0
    10.369 ( 0.005 ms): gdb/6228 ptrace(request: 12, pid: 6249, data: 140731401604352)                 = 0
    10.375 ( 0.002 ms): gdb/6228 ptrace(request: 13, pid: 6249, data: 140731401604352)                 = 0
    10.396 ( 0.001 ms): gdb/6228 ptrace(request: 7, pid: 6249, addr: 0x1)                              = 0
    10.560 ( 0.002 ms): gdb/6228 ptrace(request: 12, pid: 6249, data: 140731401604064)                 = 0
    10.564 ( 0.001 ms): gdb/6228 ptrace(request: 16898, pid: 6249, data: 140731401607616)              = 0
    10.566 ( 0.001 ms): gdb/6228 ptrace(request: 12, pid: 6249, data: 140731401604096)                 = 0
    10.568 ( 0.001 ms): gdb/6228 ptrace(request: 13, pid: 6249, data: 140731401604096)                 = 0
    10.666 ( 0.002 ms): gdb/6228 ptrace(request: 12, pid: 6249, data: 140731401603440)                 = 0
    10.670 ( 0.001 ms): gdb/6228 ptrace(request: 13, pid: 6249, data: 140731401603440)                 = 0
    10.675 ( 0.002 ms): gdb/6228 ptrace(request: 9, pid: 6249, addr: 0x1)                              = 0
    10.687 ( 0.001 ms): gdb/6228 ptrace(request: 12, pid: 6249, data: 140731401604064)                 = 0
    10.690 ( 0.001 ms): gdb/6228 ptrace(request: 16898, pid: 6249, data: 140731401607616)              = 0
    10.692 ( 0.001 ms): gdb/6228 ptrace(request: 3, pid: 6249, addr: 0x380, data: 140731401607256)     = 0
    10.709 ( 0.001 ms): gdb/6228 ptrace(request: 12, pid: 6249, data: 140731401604272)                 = 0
    10.711 ( 0.001 ms): gdb/6228 ptrace(request: 13, pid: 6249, data: 140731401604272)                 = 0
    10.716 ( 0.001 ms): gdb/6228 ptrace(request: 3, pid: 6249, addr: 0x380, data: 140731401607768)     = 0
    10.721 ( 0.002 ms): gdb/6228 ptrace(request: 7, pid: 6249, addr: 0x1)                              = 0
    10.860 ( 0.002 ms): gdb/6228 ptrace(request: 12, pid: 6249, data: 140731401604064)                 = 0
    10.864 ( 0.001 ms): gdb/6228 ptrace(request: 16898, pid: 6249, data: 140731401607616)              = 0
    10.866 ( 0.001 ms): gdb/6228 ptrace(request: 12, pid: 6249, data: 140731401604096)                 = 0
    10.869 ( 0.002 ms): gdb/6228 ptrace(request: 13, pid: 6249, data: 140731401604096)                 = 0
    92.068 ( 0.006 ms): gdb/6228 ptrace(request: 3, pid: 6249, addr: 0xa8, data: 140731401605624)      = 0
    92.244 ( 0.003 ms): gdb/6228 ptrace(request: 12, pid: 6249, data: 140731401603440)                 = 0
    92.249 ( 0.002 ms): gdb/6228 ptrace(request: 13, pid: 6249, data: 140731401603440)                 = 0
    92.257 ( 0.003 ms): gdb/6228 ptrace(request: 9, pid: 6249, addr: 0x1)                              = 0
    92.393 ( 0.002 ms): gdb/6228 ptrace(request: 12, pid: 6249, data: 140731401603936)                 = 0
    92.397 ( 0.001 ms): gdb/6228 ptrace(request: 16898, pid: 6249, data: 140731401607488)              = 0
    92.400 ( 0.001 ms): gdb/6228 ptrace(request: 3, pid: 6249, addr: 0x380, data: 140731401607128)     = 0
    92.459 ( 0.001 ms): gdb/6228 ptrace(request: 3, pid: 6249, addr: 0xa8, data: 140731401607128)      = 0
    92.469 ( 0.001 ms): gdb/6228 ptrace(request: 12, pid: 6249, data: 140731401604272)                 = 0
    92.471 ( 0.001 ms): gdb/6228 ptrace(request: 13, pid: 6249, data: 140731401604272)                 = 0
    92.477 ( 0.001 ms): gdb/6228 ptrace(request: 3, pid: 6249, addr: 0x380, data: 140731401607768)     = 0
    92.482 ( 0.001 ms): gdb/6228 ptrace(request: 7, pid: 6249, addr: 0x1)                              = 0
```
可以看到，gdb频繁的调用ptrace来获取寄存器并修改指针寄存器的值。
# 如何防止程序被调试
根据man-page的文档，可以知道，ptrace只能被一个人去attach，所以防止程序被调试的方法很简单，那就是主动调用TRACEME让父进程来调试自己， 如下
```
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <signal.h>
#include <sys/prctl.h>
#include <sys/ptrace.h>

int main()
{
    if (ptrace(PTRACE_TRACEME, 0, 0, 0) < 0 ) {
        exit(42);
    }
    while(1) {
        printf("hello \n");
        sleep(1);
    }
    return 0;
}
```
这里使用PTRACE_TRACEME来让父进程调试自己，那么可以从程序运行后看到如下信息
```
# cat /proc/$(pidof hello)/status | grep TracerPid
TracerPid:      5071
```
这里可以看到自己被attach的pid是5071，而5071是自己程序运行的父进程bash。此时因为ptrace只能被一个人trace，所有其他的程序无法调试它。此时可以尝试gdb调试此程序
```
# gdb attach 6526
Attaching to process 6526
Could not attach to process.  If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf
warning: process 6526 is already traced by process 5071
```
可以看到其他程序无法调试此程序。

同样的程序也无法在运行时被调试，如下
```
# gdb ./hello
(gdb) r
Starting program: /root/gdb/hello
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Inferior 1 (process 6578) exited with code 052]
```
# 总结
到了这里，可以知道了gdb本身是ptrace的封装，其利用内核实现的ptrace机制来完成程序的调试，从而获取当前代码运行时刻的寄存器，内存，栈等相关信息。

那么我有一个问题，如何尝试让TracerPid为0，从而伪装自身并未已被参与调试。

gdb调试方法(2)-ptrace

gdb是工作中常用的调试工具，朋友说要介绍一下gdb的使用方法，思考了一下，遂打算整理自己的gdb经验，总结出来作为一个系列，一方面用作巩固自己的基础知识，另一方面用来分享自己的一些经验和技巧。

# 参考资料
我使用gdb的所有技巧来源于两个链接，如果想一手资料学习理解，可以进如下链接学习

## gdb文档
> https://sourceware.org/gdb

这里是gdb的官方文档位置，会每日构建文档查看，链接如下

> https://sourceware.org/gdb/current/onlinedocs/gdb.html

pdf版本
> https://sourceware.org/gdb/current/onlinedocs/gdb.pdf

## 100个gdb技巧
> https://github.com/hellogcc/100-gdb-tips

这是整理的关于gdb的中文文档

# 总结
如果需要了解gdb的使用，上述文档完全能够达成目的。接下来主要针对自己的gdb经验做一个总结，和上述内容仅技术相关。