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 <sys/types.h>
#include <unistd.h>
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 的方式，可以沿用已有的项目编译方法，也无需添加额外的相关依赖。个人认为是一种更通用和简单的调试方法，行文如有出错，欢迎指正。
