Gdb

k8s 容器热替换/重启主过程 - gdb execve syscall 法 指标k8s 环境下，在不进行或重启 container 的状况下，重启利用过程(pid:1)，甚至从新加载运行新版本的利用。本文以 gdb 作为工具，调用内核的 close / execve syscall，去实现这个指标。 背景K8s 显然曾经由衰亡转向成熟。大潮过后，是时候思考一下，当初吹过的牛有哪些是真的，哪些是还未对现的。不可否认，k8s 改革了运维的工作形式，这根本是提高的。但对于开发，特地是阻碍问题定位、程序调试办法，显然难度是减少了。 在利用的阻碍问题定位、程序调试时，咱们时常心愿能在雷同的环境下反复重启利用，去察看咱们对配置的批改，或者程序的更新是否真正解决了问题。要实现这个指标，通常须要： 批改利用代码，跑 CI pipeline 从新打包 docker image，上传。—— 费时费力 想方法重启容器。—— 环境毁坏了，问题可能重现不了 如果容器启动脚本设计时就反对重启，当然没问题，但大部分状况下，均是不间接反对的，很多时候，利用主过程就间接是 container 的主过程 pid:1 了。 我钻研过三个办法去替换主过程： gdb 调用 libc 的 execl 。gdb 调用 syscall execve 。 这个办法比较复杂，但也更通用，这是本文要说的办法。kill -STOP 挂起主过程的父过程gdb 主过程的父过程，让它收不到 SIGCHLD知识点Linux 的一些内存布局Linux 的过程启动参数和环境变量布局Linux /proc/$pid/stat 的小机密syscall 常识x86 一点寄存器常识gdb 大法之魔幻系列简介《k8s 容器热替换/重启主过程》 是一个系列的文章，指标都是雷同的，但在不同的状况下应用不同的伎俩： k8s 容器热替换/重启主过程 - gdb exec 法 长处：应用比拟不便毛病：依赖可执行文件应用了 glibc.so 。 golang 编写生成的可执行文件，通常不应用 glibc.sok8s 容器热替换/重启主过程 - gdb execve syscall 法（本文） ...

首先编译sample.c，切记要应用“-g”选项生成调试信息：gcc -g -o sample sample.c分屏调试gdb -tui sample列出源码list在第16行设置断点 break 16 简化: b 16在函数funcABC()入口处设置断点 break funcABC查看断点信息 info break 简化:i b运行程序 run单条语句执行 next 简化: n打印变量 a 的值 print a 简化: p a以十六进制模式打印 变量a print /x a以二进制模式打印 变量a print /t a以更具体的状况打印 变量a ptype a查看函数堆栈 backtrace 简化:bt退出函数 finish单步调试,会进入函数外部 step间接enter回车会执行上一步命令 删除说与断点 delete革除第N行下面的所有断点 clear N持续运行程序,直至下个断点 continue终止正在的调试 kill

应用gdb ./XX时，gdb过程fork出子过程，调用ptrace(PTRACE_TRACEME)零碎调用跟踪，而后exec替换可执行文件ptrace十分弱小，它容许跟踪过程读写被跟踪过程的代码空间、数据空间、堆栈、寄存器组的值，而且接管了操作系统发给被跟踪过程的信号应用gdb attach pid的时候，gdb过程收养了被跟踪过程，调用了ptrace(PTRACE_ATTACH)如何实现断点指令：将断点处代码贮存到断点链表，插入中断代码；当产生中断时，操作系统发信号被gdb截获，查问断点链表 将断点代码写回从新设置PC指向断点

前言应用gdb+jlink的形式比较简单，这里简略说说吧。 下载安装jlink第一步，去官网下载安装：https://www.segger.com/downlo... 应用J-Link GDB Server关上J-Link GDB Server，依据理论状况抉择指标设施和调试接口 点击OK运行GDB Server 运行GDB在OneOS代码根目录下运行OneOS-Cube，执行如下命令运行GDB arm-none-eabi-gdb.exe .\out\stm32f401-vet-oneos\oneos.elf在GDB命令行交互界面中执行如下命令连贯GDB Server，其中:2331是GDB Server的tcp端口号，对应下面J-Link GDB Server运行时指定的gdb_port。 target remote localhost:2331连贯胜利后，GDB命令行交互界面如下 而后，就是失常的调试流程了！ 关注&&分割gitee： https://gitee.com/cmcc-oneos/OneOS-Lite docs： https://oneos-lite.com/

1.前言当咱们遇到问题的时候，能够加打印信息追踪流程，但更无效的形式是：调试。如果你应用的是keil，能够借助stlink或者jlink进行调试。如果你是应用的gnu工具链，硬件反对jlink，那么咱们能够借助gdb+jlink的形式进行调试；如果咱们硬件反对的是stlink，则能够借助gdb+openocd+stlink进行调试。 2.应用GDB调试OneOSGDB，全称GNU Project debugger，是UNIX及UNIX-like下的弱小调试工具，同时也反对对嵌入式零碎进行调试。对嵌入式零碎进行调试时，是以近程调试的形式进行的，调试环境的软硬件连贯如下： 在上图的构造中，反对嵌入式芯片调试的GDB Server有多款，这里次要介绍OpenOCD和J-Link GDB Server。 J-Link GDB Server由SEGGER公司推出，仅反对应用Jlink作为调试适配器进行调试OpenOCD，全称Open On-Chip Debugger，是一款针对嵌入式芯片调试的开源软件，反对市面上大多数的调试适配器，例如stlink、DAPlink、Jlink等。OpenOCD反对GDB查看RTOS线程，OneOS已对其进行了适配。应用OpenOCD作为GDB Server，能够查看OneOS所有线程的调用栈和栈上的长期变量，对于调试，能提供更多的信息3.gdb联合stlink调试这里以万耦开发板stm32f401-vet-oneos为例演示调试过程，因为OpenOCD配合Jlink应用时，须要将Jlink的驱动切换成通用usb驱动（OpenOCD不反对Jlink的原生驱动，如果须要，能够应用zadig这款开源软件将Jlink驱动切换成WinUSB或libusb），为了不便起见，在应用OpenOCD调试时，调试适配器抉择stlink。 3.1 获取OpenOCD下载预编译的Windows版本请点击OpenOCD下载。 3.2 目录构造OpenOCD编译后的二进制文件目录构造如下： 3.2 增加环境变量OPENOCD_BIN_PATH="D:\Program\openocd\bin"OPENOCD_SCRIPT_PATH="D:\Program\openocd\share\openocd\scripts"3.3 配置文件oneos.cfg在stm32f401-vet-oneos工程目录下创立配置文件oneos.cfg，文件内容如下: # this need match your debug adaptor and target devicesource [find interface/stlink-v2.cfg]source [find target/stm32f4x.cfg]# config openocd support OneOS$_TARGETNAME configure -rtos oneos# halt target after gdb attached$_TARGETNAME configure -event gdb-attach { halt }3.4 启动openOCD在OneOS-Lite代码根目录运行OneOS-Cube，执行如下命令: %OPENOCD_BIN_PATH%\openocd.exe -c "gdb_port 5000" -s %OPENOCD_SCRIPT_PATH% -f .\projects\stm32f401-vet-oneos\oneos.cfg运行胜利后的界面如下，此时OpenOCD已配置实现: 4 启动gdb调试在OneOS-Lite代码根目录下运行OneOS-Cube，执行如下命令运行GDB arm-none-eabi-gdb.exe .\out\stm32f401-vet-oneos\oneos.elf在GDB命令行交互界面中执行如下命令连贯GDB Server，其中:5000是GDB Server的tcp端口号，对应下面OpenOCD运行时指定的gdb_port（如果应用J-Link GDB Server，则端口抉择下面显示的2331） ...

前言咱们曾经应用renode仿真开发OneOS-Lite物联网操作系统，并应用模拟出的串口，输入了Hello OneOS-Lite。而想要更深刻地理解零碎的执行流程，或者解决程序的bug，领有调试的伎俩，必不可少！ 本篇文章将从调试的角度登程，基于Renode，应用gdb调试OneOS-Lite物联网操作系统。通过调试OneOS-Lite，也能够更加直白地理解她。 renode调试反对Renode反对应用 GDB 调试在仿真机器上运行的应用程序。 它应用 GDB 近程协定，并反对应用最常见的 GDB 函数，如断点，观察点，单步，内存拜访等。 在实在硬件上调试最重要的区别是：当仿真的CPU进行时，虚构工夫不会停顿。这使得调试过程对于仿真机器来说是通明的。 编译程序首先，当然是编译程序，这里咱们应用的是OneOS-Lite下的STM32F407VG-renode我的项目，进入该我的项目中，编译生成elf文件。倡议克隆源码仓库https://gitee.com/cmcc-oneos/OneOS-Lite，体验尝试。 创立仿真在文章《应用renode仿真开发OneOS-Lite物联网操作系统》，咱们曾经实战操作过如何进行仿真的全过程。为了简化操作，咱们曾经把步骤写成了脚本文件stm32f4_discovery.resc，放在STM32F407VG-renode我的项目中。 应用以下命令： include @D:\gitee\OneOS-Lite\projects\STM32F407VG-renode\stm32f4_discovery.resc 连贯gdb在renode监视器中运行以下指令，咱们能够在端口 3333 上启动 GDB 服务器: (machine-0) machine StartGdbServer 3333 咱们能够自行抉择适当的工具链启动 GDB，并连贯到远程目标(这里咱们抉择的是CUBE工具自带的GDB调试程序): $ arm-none-eabi-gdb /path/to/application.elf(gdb) target remote :3333在elf程序的目录下，执行以上命令（这样能够罢黜门路的懊恼）： 开始调试GDB 连贯到renode后，仿真就能够开始了。仅仅通知 GDB 持续，并不足以启动程序，这是咱们还要通知renode监视器，能力得以调试持续。 (gdb) monitor start(gdb) continue在此之后，咱们就能够像失常应用gdb调试程序的样子，单步、断点、查看栈档次等等。 关注&&分割gitee： https://gitee.com/cmcc-oneos/OneOS-Lite docs： https://oneos-lite.com/ 公众号：CMCC-OneOS

发现问题gdb调试时golang时 go build -gcflags "-N -l" -ldflags=-compressdwarf=false gdb/main.go呈现 gdb please check gdb is ** - see taskgated(）环境及现有配置 解决问题1. 执行以下一个脚本#!/bin/bash# This script is copied from https://github.com/llvm/llvm-project/blob/master/lldb/scripts/macos-setup-codesign.shCERT="gdb_codesign"function error() { echo error: "$@" 1>&2 exit 1}function cleanup { # Remove generated files rm -f "$TMPDIR/$CERT.tmpl" "$TMPDIR/$CERT.cer" "$TMPDIR/$CERT.key" > /dev/null 2>&1}trap cleanup EXIT# Check if the certificate is already present in the system keychainsecurity find-certificate -Z -p -c "$CERT" /Library/Keychains/System.keychain > /dev/null 2>&1if [ $? -eq 0 ]; then echo Certificate has already been generated and installed exit 0fi# Create the certificate templatecat <<EOF >$TMPDIR/$CERT.tmpl[ req ]default_bits = 2048 # RSA key sizeencrypt_key = no # Protect private keydefault_md = sha512 # MD to useprompt = no # Prompt for DNdistinguished_name = codesign_dn # DN template[ codesign_dn ]commonName = "$CERT"[ codesign_reqext ]keyUsage = critical,digitalSignatureextendedKeyUsage = critical,codeSigningEOFecho Generating and installing gdb_codesign certificate# Generate a new certificateopenssl req -new -newkey rsa:2048 -x509 -days 3650 -nodes -config "$TMPDIR/$CERT.tmpl" -extensions codesign_reqext -batch -out "$TMPDIR/$CERT.cer" -keyout "$TMPDIR/$CERT.key" > /dev/null 2>&1[ $? -eq 0 ] || error Something went wrong when generating the certificate# Install the certificate in the system keychainsudo security add-trusted-cert -d -r trustRoot -p codeSign -k /Library/Keychains/System.keychain "$TMPDIR/$CERT.cer" > /dev/null 2>&1[ $? -eq 0 ] || error Something went wrong when installing the certificate# Install the key for the certificate in the system keychainsudo security import "$TMPDIR/$CERT.key" -A -k /Library/Keychains/System.keychain > /dev/null 2>&1[ $? -eq 0 ] || error Something went wrong when installing the key# Kill task_for_pid access control daemonsudo pkill -f /usr/libexec/taskgated > /dev/null 2>&1# Exit indicating the certificate is now generated and installedexit 02. 创立 钥匙串钥匙串拜访-证书助理-创立证书-名称临时为 gdb-cert，勾选☑️然我笼罩这些默认值一路点创立，到了这个地位选 零碎 ...

disable/enable (gdb) info bNum Type Disp Enb Address What1 breakpoint keep y 0x0000000000a3c27a in InvalidateCatalogSnapshot at snapmgr.c:566 breakpoint already hit 3 times2 breakpoint keep y 0x00000000004e9fc6 in systable_beginscan at genam.c:361(gdb) disable b 1(gdb) enable b 1

问MySQL 中在运行一个 DDL , 此时咱们对这个 DDL 进行 kill , 那这个 DDL 多久会被 kill 掉? 要探讨这个问题, 咱们须要拆分问题: DDL 多久会被 kill 掉 = DDL 多久会开始 kill + DD L的回滚收尾操作进行了多久 本试验只探讨如何察看: DDL 多久会开始 kill 试验参考第16问, 咱们起一个数据库, 并让其在调试模式运行. 首先宽油起一个数据库实例: 改一下 start 脚本, 配置成调试模式: 重启数据库, 启动的时候减少 –debug 参数: 拜访数据库, 确认是调试版本: 创立一张简略的表, 塞 4 行数据进去: 当初写一个简略的 gdb 脚本: 这个脚本里, 咱们在 trx_is_interrupted 函数上设置了一个断点. trx_is_interrupted 函数是 InnoDB 查看以后线程是否被 kill 的函数, 当调用这个函数时,InnoDB 才会查看以后是否有 kill 操作, 如果有, 则进行相应的解决. ...