一文带你看透 GDB 的 实现原理 -- ptrace真香

最新推荐文章于 2024-05-03 14:43:21 发布
最新推荐文章于 2024-05-03 14:43:21 发布
阅读量5k 收藏 54
点赞数 14
分类专栏： # linux操作系统：常用命令 linux 操作系统技能树
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Z_Stand/article/details/108395906
版权

文章目录


GDB本身能够attach到一个运行的进程，实时获取运行中进程的内存数据，增加断点，查看当前运行状态下函数变量值，甚至直接修改函数的变量。

这个机制本身就很有趣，也很实用，接下来探索一下GDB核心功能的详细实现。

GDB基本的调试功能都是通过一个系统调用ptrace来实现的。

ps: 限于本人能力有限，对底层CPU 执行的正确逻辑没法做到万无一失，欢迎大家批评指正，相互学习讨论。

Ptrace 的使用

ptrace 主要被用做进程追踪，追踪进程的什么内容呢？这里有很多可选的配置，比如进程内存的值、进程寄存器的值，进程接收到的信号，指定进程以何种方式运行等等；

接口声明如下:

#include <sys/ptrace.h>

long ptrace(enum __ptrace_request request, pid_t pid,
            void *addr, void *data);

调用ptrace 追踪进程时(gdb attach -p $pid)，被追踪进程会发生如下事情：

  • 追踪进程会变为被追踪进程 的父进程

    Baron+ 215677 154756  0 11:57 pts/1    S      0:00  |   \_ gdb attach -p 215063           
Baron+ 218064 215677  7 11:59 pts/1    S+     0:00  |       \_ /home/Baron/write_test

  • 进程状态会进入 TASK_TRACED ，表示当前进程正在被追踪，此时进程会暂停下来，等待追踪进程的操作。这个状态有点像TASK_STOPPED，都是让进程暂停下来等待被唤醒或者操作。只是TASK_TRACED状体的进程 不接受SIGCONT信号，只接受ptrace指定的PTRACE_DETACH和PTRACE_CONT 请求从而唤醒进程执行操作。

  • 发送给被追踪进程的信号会被转发给父进程，除了SIGKILL，子进程则会被阻塞。

  • 父进程收到信号之后可以对子进程进行修改，来让子进程继续运行。

接下来描述一下ptrace接口的参数含义：

  • request 作为ptrace的核心配置，提供非常多的进程追踪能力

    • PTRACE_TRACEME 和 PTRACE_ATTACH 都是和进程建立追踪关系

      • PTRACE_TRACEME表示被追踪进程调用，让父进程来追踪自己。通常是gdb调试新进程时使用。
      • PTRACE_ATTACH父进程attach到正在运行的子进程上，这种追踪方式会检查权限，普通用户无法追踪root用户下的进程

    • PTRACE_PEEKTEXT 、PTRACE_PEEKDATA、PTRACE_PEEKUSER、PTRACE_GETREGS等表示读取子进程内存，寄存器等内容

    • PTRACE_POKETEXT,PTRACE_POKEDATA,PTRACE_POKEUSR等表示修改子进程的内存，寄存器的内容

    • PTRACE_CONT，PTRACE_SYSCALL, PTRACE_SINGLESTEP表示被控制进程以何种方式追踪

      • PTRACE_CONT表示重新启动被追踪进程
      • PTRACE_SYSCALL每次进入或者退出系统调用时都会触发一次SIGTRAP(Trace/breakpoint trap)，strace的追踪系统调用就是通过该配置进行追踪的，进入时获取参数，退出时获取系统调用返回值。
      • PTRACE_SINGLESTEP 每执行完一次指令之后会触发一次sigtrap,支持获取当前进程的内存/寄存器状态。gdb的next指令通过该选项实现。

    • PTRACE_DETACH, PTRACE_KILL解除父子进程之间的追踪关系

      如果父进程在在子进程前结束，则会自动解除追踪关系。

  • pid表示 要跟踪的进程pid

  • addr表示进程的内存地址

  • data 根据前面设置的requet选项而变化，比如要开始追踪时则设置request= PTRACE_CONT,同时将data设置为对应signal数字(SIGTRAP – 5)。

GDB 的基本实现原理

gdb调试的基本架构如下

  • 本地调试 通过本地gdb 命令行或者mi图形接口进行调试
  • 远端调试 就是在当前设备通过远端的gdb server对远端设备的目标程序进行调试

两者共同点是 底层都通过ptrace系统调用进行调试。

在这里插入图片描述

ptrace的基本使用我们已经看了一遍，如果想要了解更加详细的信息，可以通过man 2 ptrace进一步了解。

接下来通过ptrace来简单看一下gdb的实现原理：

  • 当我们使用gdb设置断点的时候，gdb会将断点处的指令修改为INT 3（x86开始支持的专门用作调试的CPU指令，使得cpu终端到调试器），同时将断点信息以及修改前的指令保存起来。
  • 当被调试的子进程执行到断点处时 触发INT 3中断，从而产生SIGTRAP信号。
  • 因为此时父进程已经和调试进程建立追踪关系，ptrace会将子进程的SIGTRAP信号发送给父进程，此时父进程先和已有的断点信息进行对比，比如确认INT 3指令的位置，来确认当前信号是否因为断点产生。
  • 如果是，则会等待用户输入指令，进行下一步处理，如果不是，则不予理会，继续执行后续代码。

通过以上原理可以看出，gdb会修改子进程的代码（将设置断点处的子进程指令修改为INT 3），那就涉及到修改子进程内存的情况了。这里是通过ptrace的PTRACE_POKEDATA选项进行修改。

Example1 通过ptrace 修改 被追踪进程的内存数据

通过ptrace 修改 被追踪进程的内存数据

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#include <sys/ptrace.h>

void check(long ret, char *str) {
    if (ret == -1) {
        printf("execute %s failed with %ld !!!\n", str, ret);
    }
    printf("Execute %s success! \n", str);
}


char str[] = "Ptrace is testing";

int main() {
    pid_t pid = fork();

    union{
      char cdata[8];
      u_int64_t data; 
    }u = {"CHANGE T"};

    switch (pid)
    {
    case 0: // 子进程先休眠2秒
        sleep(2); 
        printf("Child's data is %s\n", str);
        break;

    case -1:
        printf("Fork failed ");
        exit(1) ;
        break;

    default: // 父进程先修改子进程内存中的值，但是父进程内存中的数据不变
        check(ptrace(PTRACE_ATTACH, pid ,0 ,0),"PT_ATTACH"); // 链接到子进程
        check(ptrace(PTRACE_POKEDATA, pid ,str ,u.data),"PT_WRITE_D"); // 修改子进程内存中str的内容
        check(ptrace(PTRACE_CONT, pid ,0 ,0),"PT_CONTINUE"); // 子进程继续运行
        printf("Parent's data is %s\n", str);
        wait(NULL);
        break;
    }

    return 0;
}

执行结果如下，可以看到父进程已经将子进程内存中的str数据前8个字节做了更改，但是父进程内存中的数据还是没有变化。

$ ./ptrace_change 
Execute PT_ATTACH success! 
Execute PT_WRITE_D success! 
Execute PT_CONTINUE success! 
Parent's data is Ptrace is testing
Child's data is CHANGE Ts testing
Example2 通过ptrace 对被追踪进程进行单步调试

通过ptrace 对被追踪进程进行单步调试，以下代码是在32位系统上调试的，所以寄存器的表示还是eip,而x86_64的系统下寄存器都已经变更为rip了。

总体的逻辑如下：

  • 追踪给定的进程pid， 通过PTRACE_ATTACH作为父进程与 给定进程建立追踪关系
  • 获取被追踪进程的 CPU存放的下一个指令的存放地址 — EIP，CPU 存放当前主线程的栈顶指针偏移地址 — ESP
  • 通过ptrace的PTRACE_SINGLESTEP选项不断得将EIP和ESP指针向下移动，每执行一条指令，寄存器指针移动一次，直到两个寄存器指针到达栈尾，结束调试

当然打印并不只打印寄存器的地址，像GDB每一次单步追踪会等待用户的输入，这个时候可以查看或者修改esp和eip当前状态下的进程内存中的数据。

看ptrace测试 代码之前先简单描述一下ESP和EIP寄存器的关系：

进程开始运行的时候，左侧CPU的ESP寄存器指向主线程的函数栈顶（函数的执行是不断得压栈和弹栈的）
右侧的EIP寄存器则保存CPU执行的下一条汇编指令（后文有一个简单的测试程序的全指令截图，可以看看）
在这里插入图片描述
当开始运行的时候，一个函数语句可能需要多条汇编指令来完成，所以EIP改变多次，ESP才会发生一次改变。
在这里插入图片描述
在这里插入图片描述
通过n次的指令执行程序主体代码， 运行完成的标记就是ESP指向函数栈底，EIP指令指针也指向函数栈底。
在这里插入图片描述

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <wait.h>
#include <sys/ptrace.h>
#include <sys/reg.h>
#include <sys/user.h>
#include <sys/signal.h>

#define M_OFFSETOF(STRUCT, ELEMENT) \
	(unsigned int) &((STRUCT *)NULL)->ELEMENT;

#define D_LINUXNONUSRCONTEXT 0x40000000 // 32位系统下内核态部分的结束地址
  																			//（32位系统虚拟进程空间内核地址占用1个G）

int main (int argc, char *argv[]) 

{

int Tpid, stat, res;
int signo;
int ip, sp;
int ipoffs, spoffs;
int initialSP = -1;
int initialIP = -1;
struct user u_area;
struct user_regs_struct regs;


/*
** 传入指定进程的PID 
*/
	if (argv[1] == NULL) {
		printf("Need pid of traced process\n");
		printf("Usage: pt  pid  \n");
		exit(1);
	}
	Tpid = strtoul(argv[1], NULL, 10);
	printf("Tracing pid %d \n",Tpid );
/*
** 获取EIP 偏移地址 -- 保存CPU 下一个指令的寄存器地址
** 获取ESP 偏移地址 -- 保存CPU 函数栈顶指针的偏移地址
*/
	ipoffs = M_OFFSETOF(struct user, regs.eip);
	spoffs = M_OFFSETOF(struct user, regs.esp);
/*
** 通过Ptrace 将输入PID所代表的进程作为当前进程的子进程，并建立追踪关系。
** 此时会目标子进程发送一个SIGSTOP的信号，调用waitpid来感知子进程的状态变化。
*/
	printf("Attaching to process %d\n",Tpid);
	if ((ptrace(PTRACE_ATTACH, Tpid, 0, 0)) != 0) {;
		printf("Attach result %d\n",res);
	}
	res = waitpid(Tpid, &stat, WUNTRACED);
	if ((res != Tpid) || !(WIFSTOPPED(stat)) ) {
		printf("Unexpected wait result res %d stat %x\n",res,stat);
		exit(1);
	}
	printf("Wait result stat %x pid %d\n",stat, res);
	stat = 0;
	signo = 0;
/*
** 完成子进程（输入的PID 进程）的状态切换，并且与当前追踪进程建立了父子关系
*/
	while (1) {
/*
** 通过ptrace的PTRACE_SINGLESTEP进行单步调试，调试过程会向子进程发送SIGTRAP信号
** 通过wait系统调用进行捕获
*/ 
		if ((res = ptrace(PTRACE_SINGLESTEP, Tpid, 0, signo)) < 0) {
			perror("Ptrace singlestep error");
			exit(1);
		}
		res = wait(&stat);
/*
** 捕获到SIGTRAP信号之后，将信号置0，准备开启下一个单步调试。
** 如果发现子进程接受到的信号是SIGHUP和SIGINT（子进程接受到了暂停信号
** 那么就停止单步调试，父进程退出。
*/
		if ((signo = WSTOPSIG(stat)) == SIGTRAP) {
			signo = 0;
		}
		if ((signo == SIGHUP) || (signo == SIGINT)) {
			ptrace(PTRACE_CONT, Tpid, 0, signo);
			printf("Child took a SIGHUP or SIGINT. We are done\n");
			break;
		}
/*
** 单步调试之后，两个寄存器的地址会发生变化，所以需要重新获取以下
*/
		ip = ptrace(PTRACE_PEEKUSER, Tpid, ipoffs, 0);
		sp = ptrace(PTRACE_PEEKUSER, Tpid, spoffs, 0);
/*
** 通过 ldd 查看输入的PID进程的内存分布如下
**     libc.so.6 => /lib/i686/libc.so.6 (0x40030000)
**     /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
** 这里跳过内核态的地址
*/
		if (ip & D_LINUXNONUSRCONTEXT) {
			continue;
		} 
		if (initialIP == -1) {
			initialIP = ip;
			initialSP = sp;
			printf("---- Starting LOOP IP %x SP %x ---- \n",
						initialIP, initialSP);
		} else { // 直到运行到ESP指针和EIP指针的结尾，完成单步追踪
			if ((ip == initialIP) && (sp == initialSP)) {
				ptrace(PTRACE_CONT, Tpid, 0, signo);
				printf("----- LOOP COMPLETE -----\n");
				break;
			}
		}
		printf("Stat %x IP %x SP %x  Last signal %d\n",stat, ip, sp,
							signo);
	}
	printf("Debugging complete\n");

	sleep(5);
	return(0);
}

测试代码如下：

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>


int main() {

  int *a[10] = {0};
  int i = 0;
  int j = 0;
  
  while(i < 1000) {
    a[i] = (int *)malloc(sizeof(int)*10);
    if(a[i] == NULL){
      printf("malloc failed\n");
      exit(1);
    }else {
      printf("malloc address is %x\n",(unsigned int)a[i]);
    }
    
    for(;j < 10; ++j){
      a[i][j] = j;
    }

    i++;
    sleep(1);
  }

  for(i =0;i < 1000 ;++i) {
    free (a[i]);
  }

  return 0;

}

测试代码对应的CPU指令如下
perf top -p pid

先运行测试代码，再编译运行ptrace追踪代码./test_ptrace $pid，可以看到ptrace追踪代码如下输出:
其中IP和SP指向的地址可看到 SP指针不会每次追踪都发生变化，而指令寄存器地址IP每次都发生变化，因为每次执行的指令都不一样，这和我们描述ptrace单步调试代码逻辑时的ESP和EIP寄存器关系图逻辑一样的。

因为还不是linux手艺人，还没法深入浅出linux系统，所以这里只能通过自己的猜测和工具来 弥补体系结构这块知识的缺失了。

Tracing pid 314201 
Attaching to process 314201
Wait result stat 137f pid 314201
---- Starting LOOP IP a88e0840 SP b60b6418 ----
Stat 57f IP a88e0840 SP b60b6418  Last signal 0
Stat 57f IP a88e0846 SP b60b6418  Last signal 0
Stat 57f IP a88e0848 SP b60b6418  Last signal 0
Stat 57f IP a88e06f4 SP b60b6420  Last signal 0
Stat 57f IP a88e06f6 SP b60b6420  Last signal 0
Stat 57f IP a88e06f8 SP b60b6420  Last signal 0
Stat 57f IP a88e0720 SP b60b6420  Last signal 0
Stat 57f IP a88e0727 SP b60b65d8  Last signal 0
Stat 57f IP a88e0729 SP b60b65d8  Last signal 0
Stat 57f IP a88e072a SP b60b65e0  Last signal 0
......
Stat 57f IP a88e06ef SP b60b6420  Last signal 0
Stat 57f IP a88e0830 SP b60b6418  Last signal 0
Stat 57f IP a88e0837 SP b60b6418  Last signal 0
Stat 57f IP a88e0839 SP b60b6418  Last signal 0
Stat 57f IP a88e083e SP b60b6418  Last signal 0
----- LOOP COMPLETE -----
Debugging complete

Ptrace的实现

这里不可能将每一个ptrace的选项的实现都讲明白，只能在主线的调试流程上看看当 attach，获取被追踪进程内存数据，单步调试 这一些功能的背后内核做了什么。

使用frtrace 抓取SyS_ptrace函数的执行逻辑，关于ftrace的使用可以参考关于 Rocksdb 性能分析 需要知道的一些“小技巧“ – perf_context的“内功” ，systemtap、perf、 ftrace的颜值

这个抓取主要是通过执行gdb的一些调试命令来让ptrace的不同选项得到运行，抓取attach,breadpoint,r,n等基本gdb指令的结果如下(主体的处理逻辑还是比较长的，这里仅仅贴一部分逻辑)：

# tracer: function_graph
#
# CPU  TASK/PID         DURATION                  FUNCTION CALLS
# |     |    |           |   |                     |   |   |   |
   3)  <...>-46083   |               |  SyS_ptrace() {                           # 系统调用入口
   3)  <...>-46083   |               |    ptrace_get_task_struct() {             # 获取进程的task_struc
   3)  <...>-46083   |               |      find_task_by_vpid() {
   3)  <...>-46083   |               |        find_task_by_pid_ns() {
   3)  <...>-46083   |   0.523 us    |          find_pid_ns();
   3)  <...>-46083   |   1.178 us    |        }
   3)  <...>-46083   |   1.858 us    |      }
   3)  <...>-46083   |   2.387 us    |    }
   3)  <...>-46083   |               |    ptrace_attach() {                     # attach 入口
   3)  <...>-46083   |               |      mutex_lock_interruptible() {
   3)  <...>-46083   |   0.037 us    |        _cond_resched();
   3)  <...>-46083   |   0.707 us    |      }
   3)  <...>-46083   |   0.087 us    |      _raw_spin_lock();
   3)  <...>-46083   |               |      __ptrace_may_access() {
   3)  <...>-46083   |   0.105 us    |        get_dumpable();
   3)  <...>-46083   |               |        security_ptrace_access_check() {
   3)  <...>-46083   |               |          yama_ptrace_access_check() {
   3)  <...>-46083   |   0.068 us    |            cap_ptrace_access_check();
   3)  <...>-46083   |   0.584 us    |          }
   3)  <...>-46083   |   0.043 us    |          cap_ptrace_access_check();
   3)  <...>-46083   |   1.404 us    |        }
   3)  <...>-46083   |   2.947 us    |      }
......

ps: 后文涉及到的ptrace源码是 linux-3.10.1.0.1版本

PTRACE_TRACEME

通过gdb 调试一个新的进程会进入PTRACE_TRACEME选项，gdb ./new_process

ptrace系统调用入口如下：

确认能够建立连接之后通过_ptrace_link将当前进程new_process和gdb追踪进程建立父子关系

PTRACE_ATTACH

通过gdb attach到一个正在运行的进程上时会进入这个逻辑，gdb attach -p pid

在后续会通过signal_wake_up_state函数唤醒处于stopped状态的进程

PTRACE_CONT

使得因正在被调试而暂停，或者断掉的进程恢复运行，gdb的n,r,c等命令让进程重新运行都是通过该选项实现的

进入到arch_ptrace之后，通过ptrace_reuqest --> ptrace_resume对该选项进行处理

PTRACE_SINGLESTEP

将进程的标志寄存器设置为单步模式，让被调试进程继续运行。当执行完一条指令之后，会触发INT中断，并发信号给控制进程，等待下一次的执行。

PTRACE_PEEKDATA

读取虚拟进程内存中的数据,像gdb的p 打印变量 就是该选项的功能，与选项PTRACE_PEEKTEXT一样，只不过读取的是不同的地址空间的数据。TEXT是代码段的数据，程序执行代码中的一段数据，DATA段存储已经初始化的静态数据和全局变量数据。

PTRACE_POKEDATA

修改被追踪进程指定内存地址中的数据，通过设置access_process_vm函数最后一个参数来表示是写入内存中的数据还是从内存中读数据。

PTRACE_GETREGS

获取被追踪进程 指定寄存器中的数据

而对应的PTRACE_SETREG即修改用户进程寄存器内容，通过__get_user函数将data中的数据写入到regs数组之中。

z_stand
关注
专栏目录
centos升级gdb支持pretty-printer
baoxin1100的博客
10-20 1680
升级GDB支持pretty-printer，使用vscode调试STL
gdb的使用及原理---整理
03-30
GDB对于基于GNU系统开发的程序员来说是最基本的东西，必须的。所以这篇学习总结中，不打算包括GDB的一般使用方法。因为这些东西必须是随手拈来的。所以也就不花时间来整理，我只把一些比较高级的应用在这里作一个整理。
GDB调试原理
ad_hoc_NW的博客
04-26 945
GDB调试器可以启动某些进程，然后对其进行调试，或者将自己本身关联到一个已存在的进程之上。它可以单步运行代码，设置断点然后运行程序，检查变量的值以及跟踪调用栈等等。 gdb通过一个系统调用“ptrace”接管一个进程的执行。ptrace系统调用是一个功能众多且相当复杂的工具，能允许一个进程控制另一个进程的运行，而且可以监视和渗入到进程内部。 ptrace系统调用的原型如下： #inclu
gdb的工作原理和常用命令
最新发布
不才的专栏
05-03 141
GDB（GNU调试器）是一个强大的调试工具，用于调试各种编程语言编写的程序，如C、C++和Fortran等。GDB允许你对程序执行进行深入控制，可以检查程序在运行时的内部状态，如变量的值，内存状态，甚至是调用栈的情况等。了解GDB的工作原理有助于更有效地利用它进行调试。
GDB实现原理
biao2488890051的博客
01-18 1075
1、上篇主要对GDB的使用技巧进行了一个简单总结，其实这里的内容是和上篇总结的内容放在一块的，但是考虑到GDB的实现技术重要性和意义，所以单独拿出来，当前只做皮毛性的记录，留待以后进一步补充内容。 2、GDB基本组成： GDB由三个部分组成： （1）用户接口user interface，除支持传统的CLI接口还支持mi接口（ddd等工具使用） （2）符号处理层symbol handling，当gdb ./debugme后GDB会读取文件的符号信息，之后的原代码，变量/函数/类型的显示都由该部分...
GDB原理
qq_41306849的博客
12-18 1903
可以看到，ptrace确实是一个强大的系统调用；gdb就是基于ptrace这个系统调用来做的。其原理是利用ptrace系统调用，在被调试程序和gdb之间建立追踪关系。然后所有发送给被调试程序(被追踪线程)的信号(除SIGKILL)都会被gdb截获，gdb根据截获的信号，查看被调试程序相应的内存地址，并控制被调试的程序继续运行。GDB常用的使用方法有断点设置和单步调试，接下来我们来分析一下他们是如何实现的。 1.建立调试关系： 用gdb调试程序有2种模式，包括使用gdb启动程序，以及attach到现有进程。分
GDB的基本工作原理
把握自己。
09-22 1721
还是面某M的时候，面试官问我：“用过gdb么？” 答：“用过，调了两年bug了”。“那好，给我解释下gdb是怎么工作的？或者说跟内核什么地方有关系？”。 是阿，gdb凭什么可以调试一个程序？凭什么能够接管一个程序的运行？我以前也想过这样的问题，但是后来居然忘记去查看了。我想到了我们的二进制翻译器，想到了intel的pin，Dynamo。这些都是将翻译后的代码放到codecache中去运行，然
Linux GDB的实现原理
qq_30192655的博客
12-07 1139
在开发过程中我们都会使用 gdb 进行调试程序，那么当我们使用 gdb 进行调试程序的时候，底层发生了什么？ 今天通过分析 ptrace 系统调用来分析下 gdb 的底层实现原理。 ptrace 是什么 ptrace 是操作系统提供的一个用于跟踪进程的系统调用。通过 ptrace 系统调用可以获取被跟踪进程的进程状态。 比如我们常用的获取可执行文件执行时都进行了哪些系统调用的 strace 命令和我们常使用的调试工具 gdb 等，他们都是通过使用 ptrace 进行实现的。 在使用 gdb 进行本地跟踪某个
qtcreator-gdb-7.4-MINGW32_NT-6.1-i686.tar QT4 调试器
02-24
在这个特定的压缩包“qtcreator-gdb-7.4-MINGW32_NT-6.1-i686.tar”中，包含的是适用于32位Windows系统（MINGW32）的QT Creator调试器，针对的是NT 6.1内核，即Windows 7操作系统。 调试器是开发过程中的关键工具，...
gdb-7.0-mingw32-bin.tar.gz GDB
07-17
GDB是GNU开源组织发布的一个强大的UNIX(不仅限于UNIX)下的C/C++程序调试工具。它搭配MINGW使用，可以使用户完成整个C/C+程序的编译和运行工作。有了GDB，用户可以在调试本地的C程序时不需要第三方C/C++工具。
GDB基本调试原理及三种调试方式
04-17
详细介绍了gdb的调试原理，以及三种调试方式：调试已经创建的进程、调试新进程、远程调试；同时介绍了指令级单步的内部机理
gdb-7.2-1-mingw32
09-27
标题 "gdb-7.2-1-mingw32" 指的是一个特定版本的 GNU Debugger（GDB）软件，适用于 MingW32，这是一个 Windows 上的 MinGW（Minimalist GNU for Windows）环境的32位版本。GDB 是一款强大的开源调试器，用于C、C++...
gdb.exe下载，安装MinGW-w64缺少gdb32.exe
04-22
安装MinGW-w64 下载有的要翻墙 这了里单独下载 放到bin里就行了， ， 特别是vscode运行c/c++ debug模式 "D:\\Mingw-w64\\mingw64\\bin\\gdb.exe
【一文看懂 | GDB 底层实现原理】【转载】
j8267643的博客
02-22 1076
在程序出现bug的时候，最好的解决办法就是通过GDB调试程序，然后找到程序出现问题的地方。比如程序出现段错误（内存地址不合法）时，就可以通过GDB找到程序哪里访问了不合法的内存地址而导致的。本文不是介绍 GDB 的使用方式，而是大概介绍 GDB 的实现原理，当然 GDB 是一个庞大而复杂的项目，不可能只通过一篇文章就能解释清楚，所以本文主要是介绍 GDB 使用的核心的技术 -ptrace。
gdb的工作原理
runnerchen1的专栏
03-12 698
转载自gdb的工作原理 一、gdb简介 　　gdb：GNU debugger 　　UNIX及UNIX-like下一个强大的命令行的调试工具 　　gdb调试的整体架构如下图所示： 　　 　　可以发现gdb调试不管是本地调试还是远程调试，都是基于ptrace系统调用来实现的 　　 二、ptrace 　　ptrace系统调用的原型： long ptrace(enum __ptrac...
gdb ptrace
jgdu1981的专栏
07-14 496
http://blog.csdn.net/SilentVoid/article/details/1477439
【GDB】GDB工作原理--ptrace(让父进程可观察和控制其它进程、检查和改变其核心映像及寄存器）
bandaoyu的note
07-16 612
一、gdb简介 　　gdb：GNU debugger 　　UNIX及UNIX-like下一个强大的命令行的调试工具 　　gdb调试的整体架构如下图所示： 　　 　　可以发现gdb调试不管是本地调试还是远程调试，都是基于ptrace系统调用来实现的 　　 二、ptrace gdb凭什么可以调试一个程序？凭什么能够接管一个程序的运行？我以前也想过这样的问题，但是后来居然忘记去查看了。我想到了我们的二进制翻译器，想到了intel的pin，Dynamo。这些都是将翻译后的代码放到codecache中去.
gdb和gdb-server如何实现通过usb连接通信，请详细举例说明
05-31
gdb和gdb-server是用于进行远程调试的工具，可以通过网络或串口连接进行通信。如果需要通过USB连接进行通信，可以使用gdb的serial命令和gdb-server的gdb-remote命令来实现。 以下是使用gdb和gdb-server通过USB连接进行通信的步骤： 1. 准备USB串口转换器，将其插入开发板的USB接口。根据具体的操作系统，可能需要安装相应的驱动程序。 2. 在开发板上启动gdb-server，监听USB串口设备。例如，使用以下命令启动gdb-server监听ttyUSB0设备： ``` gdbserver /dev/ttyUSB0 :1234 ``` 其中，/dev/ttyUSB0是USB串口设备的名称，:1234是监听端口号。 3. 在开发机上启动gdb，连接到gdb-server。例如，使用以下命令连接到gdb-server： ``` gdb (gdb) target remote /dev/ttyUSB0 ``` 其中，/dev/ttyUSB0是USB串口设备的名称。连接成功后，可以在gdb中进行远程调试。 需要注意的是，使用USB连接进行通信需要使用正确的USB串口设备名称，通常可以使用dmesg命令或lsusb命令查看设备信息。另外，如果开发板和开发机之间存在防火墙或网络隔离等情况，则需要进行相应的配置以确保通信正常。
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值