性能分析之 GDB 动态修改内存变量值(C/C++)

举报
zuozewei 发表于 2021/09/14 23:04:17 2021/09/14
【摘要】 前文提到了分析的思路是从 OS 级别到代码的级别。但是到了代码级别之后呢,可能还需要动态调试代码,之前写了 Java 的应用的代码动态调试工具。

前言

前文提到了分析的思路是从 OS 级别到代码的级别。但是到了代码级别之后呢,可能还需要动态调试代码,之前写了 Java 的应用的代码动态调试工具。

请参见:

并且之前在群里也有说要写关于如何修改内存变量值的。所以这里也就写一下。
后续写系列文章的思路也是将我工作中遇得到的性能分析思路一一写出来。

GDB 的定义

这次我们来写 GDB 这个工具。来看看官方如何定义这个工具的:

GDB, the GNU Project debugger, allows you to see what is going on `inside’ another program while it executes – or what another program was doing at the moment it crashed.
GDB can do four main kinds of things (plus other things in support of these) to help you catch bugs in the act:

  • Start your program, specifying anything that might affect its behavior.
  • Make your program stop on specified conditions.
  • Examine what has happened, when your program has stopped.
  • Change things in your program, so you can experiment with correcting the effects of one bug and go on to learn about another.
    The program being debugged can be written in Ada, C, C++, Objective-C, Pascal (and many other languages). Those programs might be executing on the same machine as GDB (native) or on another machine (remote). GDB can run on most popular UNIX and Microsoft Windows variants.

就是说可以让你查看另一个程序在运行的时候“里面”都有些啥。

  1. 可以改变程序的行为;
  2. 可以停在特定的地方;
  3. 可以定位程序停止时发生了什么事;
  4. 可以动态修改一些东西;

并且它还能支持多种语言的调试,还能远程调试。

因为本文不是 GDB 工具的说明书,所以没打算把每个命令都讲一遍,只扣题修改内存变量。

起点这么高,还是要落地。

一个例子

我就随便写了几行C的代码,简单到无基础的也可以玩。
在这里插入图片描述

编译它:

gcc -g test.c -o test

我们可以用 gdb 调用,也可以选择用 cgdb 调用。cgdb 就是用来替 代gdb -tui 的,也就是加了点源代码显示的色彩啥的。看一下截图比对就知道了。

在这里插入图片描述

左边是 gdb -tui,右边是 cgdb。麻烦点的就是 cgdb 还得另装一下。其他没有什么不同。
下面我们来调试下。运行一次没有加断点的。

结果如下:

在这里插入图片描述

因为要调试,所以得先知道要调试什么。

我这小段代码就一个循环,所以我把断点设置在第 7 行循环里

(GDB 断点有多种方式:可以指定行、函数、文件名+行数、class+function、内存地址等,还可以加 if else 的语法之类的)以便一会修改内存变量。

过程如下:

在这里插入图片描述
从上面的结果来看i值的打印没有 2、3 的值了,被跳过了。

GDB 不仅可以调起来程序,也可以直接 attach 到已经启动的程序中,所以不用担心程序不是自己启动的。只要有权限收拾它,怎么都能收拾它。

可能有人会说,我根本不知道要调试什么,怎么办呢?

见到这样的问题我只能说:你还年轻,以后日子还长,总会知道滴。

(潜台词就是:要好好学习我之前写的思路。)

总结

之所以在性能分析的系列中写这样的文章,是为了说明在性能分析中,这样的思路也是在必要的时候要有的。
前面我一直说有问题要定位到代码或 SQL 或参数的层面。有时候即使我们把堆栈拿出来了,还会涉及到扯皮的事情,比如环境不一样导致的问题现象不同。所以如果有能力的话,我们就再往下走一层,就是把实际的运行数据拿出来,这样就没有什么可争辩的了。

我曾经在一个项目中就是出现了问题之后,结果开发的环境不能重现,但是生产的环境肯定有。当时让一个小伙跟了这个问题两个星期,也没把问题和对应的开发工程师说明白。我就教了他这个手段。分分钟地让开发明白哪做错了。

在性能分析的项目中,什么都有可能遇得到。

希望现在做性能分析的人能掌握越来越多的技能。

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200