添加adb功能；添加lrzsz工具；添加core dump的gdb分析功能

添加adb功能：

1.git现在a35_adb分支，执行如下操作

替换d40的如下目录并重新编译：

media

ats2853_ota_file\ota.bin

packshop\Trunk\Proj\Libs

替换内核，并重命名：内核的替换路径如下：

"/home/zhanbb/D40/0908/ax5-kernel/zboot.img" "/home/zhanbb/D40/0908/d40/packshop/Trunk/Backup/Images/kernel/kernel_D40"

adb操作：

adb devices  //连接d40的adb
adb pull /extern/err/core-hunter-11-0-0-440-18  //获取d40中的文件，注意传输文件不是在终端模式

adb shell   //adb连接终端

添加lrzsz工具

嵌入式开发——文件系统部署rz、sz命令_lrz命令-CSDN博客

1.下载源码

官网：https://ohse.de/uwe/software/lrzsz.html

2.解压编译源码，编译时要指定编译工具链，和d40的编译工具链一致

tar zxvf lrzsz-0.12.20.tar.gz
cd lrzsz-0.12.20/
CC=/opt/rockchip-linux/gcc-linaro-6.3.1-2017.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc CFLAGS=-O2 ./configure
make -j12

3.将编译出来的src/lrz和lsz复制到文件系统的/bin目录，对应代码的\d40\packshop\Trunk\Images\rootfs\bin\

4.编译代码烧录后，便能在嵌入式开发板上面使用，上传指令是lrz，下载是lsz，配合SecureCRT便能实现文件的传输

1sz core-hunter-11-0-0-399-15//传输文件到电脑

添加core dump功能

首先在rcS文件里面添加如下指令，使得在启动应用程序之前，先打开core dump功能，并指定core dump保存的地址和大小，

rm -rf /extern/err/
mkdir /extern/err/
ulimit -c 25600
echo "/extern/err/core-%e-%s-%u-%g-%p-%t" > /proc/sys/kernel/core_pattern
sync

ulimit -c unlimited//如果需要配置成无限制core dump大小选这个

设置完后，当产生错误，程序会产生core dump文件，地址为/extern/err/，然后用lrzsz把文件传出

1sz core-hunter-11-0-0-399-15

或者使用adb把文件传出

adb devices
adb pull /extern/err/core-hunter-11-0-0-440-18//注意修改文件名

将core dump文件复制到linux，执行gdb指令，注意，gdb需要和你的编译工具链配合，如我的编译工具链是/opt/rockchip-linux/gcc-linaro-6.3.1-2017.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc

那么我应该使用的gdb应该是/opt/rockchip-linux/gcc-linaro-6.3.1-2017.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gdb

指令如下

还需要注意的是hunter.debug应该和烧录的hunter要同一次编出来的，不然会有问题，所以编译完建议吧hunter.debug复制出来

注意：使用gdb指令调试core dump还需要可执行文件才行

gdb  "/home/zhanbb/D40/adb/a15-rk3308/packshop-a15/Trunk/Proj/Bin/hunter.debug"   "/home/zhanbb/D40/core/core-hunter-11-0-0-440-18"     //记得修改core-hunter-11-0-0-443-16文件名

问1:core dump+GDB的调试手段详解，并且可以使用哪些gdb指令分析core dump文件：

Core dump文件是程序异常终止时，操作系统生成的一个文件，它记录了程序崩溃时的内存、寄存器状态、堆栈信息等。通过分析core dump文件，可以帮助开发者定位程序崩溃的原因。GDB（GNU Debugger）是一种广泛使用的调试工具，能够帮助开发者分析core dump文件。下面将详细介绍如何使用GDB调试core dump文件，以及相关的GDB指令。

### 开启Core Dump文件生成

首先，确保系统允许生成core dump文件。在Linux系统中，可以通过`ulimit -c unlimited`命令来取消core文件大小的限制，从而使得在程序崩溃时能够生成core dump文件。

### 使用GDB分析Core Dump文件

1. **启动GDB**：在命令行中输入`gdb <程序名> <core文件名>`启动GDB，并加载core dump文件。例如，如果程序名为`a.out`，core dump文件名为`core.1234`，则输入`gdb a.out core.1234`。

2. **基本分析**：

   - `bt`：显示当前线程的调用栈帧（backtrace），这是最常用的调试命令之一，可以让你看到程序崩溃时的函数调用关系。

   - `info threads`：列出所有线程，对于多线程程序，可以查看哪些线程在运行。

   - `thread <num>`：切换到编号为`<num>`的线程，与`info threads`命令配合使用，可以逐个检查各个线程的状态。

3. **深入分析**：

   - `frame <n>`：选择调用栈中的第`n`个栈帧。在有了调用栈的情况下，可以通过该命令进一步查看不同栈帧的上下文。

   - `list`：显示当前执行代码的周围源代码。如果GDB能找到源代码，这个命令可以帮助理解程序崩溃时正在执行什么代码。

   - `print <expr>`：打印表达式`<expr>`的值。这可以用来查看变量的值或者表达式的结果。

   - `x/<n>f <address>`：以格式`f`（如`x`表示十六进制）显示内存地址`<address>`开始的`<n>`个单位的内容。这个命令对于分析程序的内存状态非常有用。

4. **特定情况分析**：

   - 对于段错误（Segmentation Fault）：通常需要检查导致崩溃的指针或内存访问操作，使用`x`命令检查崩溃时访问的内存地址。

   - 对于死锁：查看各线程的调用栈和锁的状态，确定是哪个资源造成的死锁。

5. **退出GDB**：输入`quit`或简写`q`退出GDB。

### 高级功能

- **设置条件断点**：如果想在特定条件下才停止程序，可以使用`break`命令的条件形式，如`break file.c:123 if x==1`。

- **查看变量的历史值**：如果开启了GDB的逆向调试功能（需要GDB支持），可以查看变量在过去的值，帮助分析变量如何变化至异常状态。

- **自动化分析**：可以编写GDB脚本自动执行一系列命令，对于复杂的分析过程，这可以大大节省时间。

通过上述方法和指令，你可以对core dump文件进行深入分析，找到程序崩溃的原因。务必记住，有效的调试是建立在对程序结构和逻辑深入理解的基础上的。因此，在使用GDB等工具时，结合对代码的熟悉和理解，才能更高效地定位问题。

问2:与直接在GDB运行程序类似， core dump文件加 载起来之后，GDB会直接显示触发问题的那一行 代码，也可以使用backtrace、print等常规命令 从core dump文件中获取信息，请详细说说如何使用backtrace、print等常规命令 从core dump文件中获取信息

当使用GDB加载core dump文件后，可以通过一系列的命令来获取程序崩溃时的详细信息。这些信息对于理解程序在崩溃时的状态非常有帮助。下面详细解释如何使用`backtrace`、`print`等常规命令从core dump文件中获取信息。

### 使用`backtrace`获取调用栈信息

1. **`backtrace`或`bt`命令**：这是分析core dump文件时最常用的命令之一。它显示了程序崩溃时的函数调用栈（也称为堆栈跟踪）。每一行代表一个栈帧，包含了函数名、源文件名和行号（如果可用）。

   

   - 使用方法：在GDB提示符下输入`backtrace`或简写`bt`后回车。

2. **查看特定栈帧的详细信息**：通过`frame <n>`或`f <n>`命令选择特定的栈帧，其中`<n>`是`backtrace`命令输出中的栈帧编号。选中栈帧后，可以更详细地查看该栈帧的上下文信息。

### 使用`print`打印变量值

1. **`print <expression>`或`p <expression>`命令**：用于打印表达式的值。这个命令非常有用，可以查看崩溃时各种变量的值。`<expression>`可以是变量名、数组元素、结构体成员等。

   - 使用方法：在GDB提示符下输入`print 变量名`或`p 变量名`后回车。

2. **查看复杂类型的变量**：对于结构体、类实例等复杂类型的变量，`print`命令同样适用。例如，如果想查看一个名为`obj`的对象的`member`成员，可以使用`print obj.member`。

### 其他相关命令

- **`info locals`命令**：显示当前栈帧中所有局部变量的值。这对于快速查看函数内部状态非常有用。

- **`list`命令**：显示当前代码的周围源代码。如果你已经通过`backtrace`定位到了问题发生的函数，使用`list`可以查看该函数的源代码，帮助理解代码逻辑。

- **`x`命令**：用于检查内存地址处的内容。格式为`x/NFU addr`，其中N是要显示的单元数，F是显示格式，U是单位大小，addr是内存地址。这对于分析指针引用、数组内容等非常有帮助。

### 实际操作示例

假设你已经加载了core dump文件，并且GDB停在了触发问题的那一行代码。你可以按照以下步骤进行：

1. 输入`bt`或`backtrace`查看调用栈。

2. 选择感兴趣的栈帧（如第0帧）使用`frame 0`。

3. 使用`info locals`查看当前栈帧的局部变量。

4. 对于特定变量，使用`print 变量名`来查看其值。

5. 如果需要查看源代码，使用`list`命令。

通过这些步骤，你可以获取大量关于程序崩溃时状态的信息，这对于诊断问题和修复bug非常有帮助。