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 的方式，可以沿用已有的項目編譯方法，也無需添加額外的相關依賴。個人認為是一種更通用和簡單的調試方法，行文如有出錯，歡迎指正。
