1. 前言
调试FFmpeg的方式有很多种。在macOS上,使用LLDB调试,功能强大,上手简单,就是相比IDE调试略显笨拙。
能不能像debug iOS工程那样debug FFmpeg呢?大致有两种思路:
- 使用External Build
很多人有相关的尝试,建立工程时选择Command Line Tool,被对应FFmpeg添加到工程。最终建立target并用External Build Tool Configuration进行build,如果相关header和Library路径设置正确,这样也是可以调试的。 - 使用Source Build
那就是建一个Cocoa APP,把需要编译的FFmpeg文件都添加到工程Compile Sources里面去。然后在ViewController里面调用main
函数,此时只能添加对应的fftools,比如ffplay(因为其他的fftools都有main
函数)。这代替了FFmpeg的Makefile编译过程,如果相关配置正确的话,还是可以run起来的。
总结就是,工程配置的复杂度较高,会出现各种Build Fail情况。
2. Chromium的debug思路
2.1 生成Chromium源码工程
Chromium使用Ninja进行项目编译,gn可以生成包含build.ninja等文件的build目录。
同时为了更方便调试,以下命令会为chrome target输出名为all.xcworkspace的xcode工程。
gn gen --ide=xcode --filters=//chrome out/Default
打开all.xcworkspace工程如下图,chrome相关文件都在里面了。
2.2 调试Chromium
Chromium是多进程模式,使用LLDB时,需要attach到需要调试的进程号。如何在进程启动的时候正确attach呢?attach到对应进程后,错过了进程初始化运行的关键点呢?
使用以下命令启动Chromium,当启动Render时,将停留在等待debugger to attach里面:
./out/Default/Chromium.app/Contents/MacOS/Chromium --renderer-startup-dialog
此时控制台输出:
[81889:775:1217/161254.237552:ERROR:content_switches_internal.cc(198)] Renderer (4586) paused waiting for debugger to attach. Send SIGUSR1 to unpause.
查看content/common/content_switches_internal.cc文件,可以看到void WaitForDebugger(const std::string& label)
函数主要使用pause()
等待LLVB attach。
此时使用Xcode Attach to Process,并且选中Chromium Helper (4586):
在 Renderer进程对应的源码里面设置断点,则可以使用我们熟悉的 Xcode工具进行分步调试了。
3. 使用Xcode debug FFmpeg
参考Chromium的调试方法,首先需要把源码添加到Xcode工程中。
然后在需要调试的某个fftools 里,在主函数int main(int argc, char **argv)
初始化最前面添加等待attach的接口。具体代码如下。
3.1 等待attach
调用wait_for_debugger ()
就会进入到pause()
里面去。
#include
#include
static int is_waiting_debugger;
//Handler for signal USR1
static void sig_usr1_handler(int signal)
{
av_log(NULL, AV_LOG_WARNING, "Received SIGUSR1 to continue.\n");
}
//Wait for debugger to attach. Send SIGUSR1 to unpause.
static void wait_for_debugger()
{
if( !is_waiting_debugger )
return;
pid_t pid = getpid();
#if defined(__APPLE__) || defined(__FreeBSD__)
const char * appname = getprogname();
#elif defined(_GNU_SOURCE)
const char * appname = program_invocation_name;
#else
const char * appname = argv[0];
#endif
av_log(NULL, AV_LOG_FATAL, "%s (%d) paused waiting for debugger to attach. Send SIGUSR1 to unpause.\n",
appname, pid);
struct sigaction sa;
memset(&sa, 0, sizeof(sa));
sa.sa_handler = sig_usr1_handler;
sigaction(SIGUSR1, &sa, NULL);
pause();
}
在等待LLDB attach时,会打印提醒:
ffplay_g (8858) paused waiting for debugger to attach. Send SIGUSR1 to unpause.
如果 LLDB attach了 8858,则会打断pause()
进入后续代码流程。
如果临时不想debug,则发送SIGUSR1继续代码执行:
kill -s USR1 8858
3.2 配置attach
并不是每次执行ffplay
都需要发送 SIGUSR1来中止debug,也是件挺麻烦的事情。所以我们需要将 debug开启 写入配置。
3.1章节已经定义了全局静态变量 is_waiting_debugger,这里没有赋初始值的原因是静态变量默认值已经是 0。
以FFmpeg代码分支 n3.4.1 中 ffplay.c 为例子,首先需要在 options 中增加 attach
选项,启动时带上该参数才能走到 debugger attach 逻辑。
static const OptionDef options[] = {
CMDUTILS_COMMON_OPTIONS
{ "x", HAS_ARG, { .func_arg = opt_width }, "force displayed width", "width" },
{ "y", HAS_ARG, { .func_arg = opt_height }, "force displayed height", "height" },
{ "s", HAS_ARG | OPT_VIDEO, { .func_arg = opt_frame_size }, "set frame size (WxH or abbreviation)", "size" },
{ "fs", OPT_BOOL, { &is_full_screen }, "force full screen" },
{ "attach", OPT_BOOL, { &is_waiting_debugger }, "force waiting for debugger to attach" },
然后在ffplay初始化输入参数后调用wait_for_debugger()
。
/* Called from the main */
int main(int argc, char **argv)
{
int flags;
VideoState *is;
init_dynload();
av_log_set_flags(AV_LOG_SKIP_REPEATED);
parse_loglevel(argc, argv, options);
/* register all codecs, demux and protocols */
#if CONFIG_AVDEVICE
avdevice_register_all();
#endif
#if CONFIG_AVFILTER
avfilter_register_all();
#endif
av_register_all();
avformat_network_init();
init_opts();
signal(SIGINT , sigterm_handler); /* Interrupt (ANSI). */
signal(SIGTERM, sigterm_handler); /* Termination (ANSI). */
show_banner(argc, argv, options);
parse_options(NULL, argc, argv, options, opt_input_file);
wait_for_debugger();
3.3 FFmpeg的调试配置
为了debug的顺畅,关闭编译优化和strip是必要的。
./configure --enable-debug=3 --disable-optimizations --disable-stripping --disable-asm --assert-level=2
4. 总结
相比使用 Xcode组织代码和工程编译后对 target进行调试,使用 Xcode attach process id 的方式,可以沿用已有的项目编译方法,也无需添加额外的相关依赖。个人认为是一种更通用和简单的调试方法,行文如有出错,欢迎指正。