Dwarf除錯資訊Consumer——gdb

1      引言

前面介紹過dwarf除錯資訊格式，內容包括有哪些型別的除錯資訊，除錯資訊的存放格式、某些除錯資訊的編碼方法等。本文的內容主要除錯資訊是怎樣被解析使用的除錯資訊作為編譯器為了實現原始碼級別除錯生成的內容，其主要的consumer自然是gdb。下面介紹gdb中如何使用dwarf除錯資訊。

本文是一個基於原始碼debug過程的分析文件，內容比較細，偏筆記性質的。總結抽象工作做得不多。所以其中的內容以及一些流程圖都會比較細節。下面提供一個總結概括性的ppt文件點選開啟連結。

2      除錯資訊回顧

在介紹gdb如何讀取dwarf除錯資訊之前，我們先回顧一下有哪些除錯資訊，除錯資訊在elf檔案中的位置。

在使用gcc編譯程式的時候，加上-g引數，那麼最後生成的目標檔案中會有除錯資訊，除錯資訊格式使用dwarf2格式。使用readelf工具加上-S引數，可以檢視目標檔案中有哪些除錯資訊section，示例如圖2-1所示。

圖 2‑1 除錯資訊類別

       可以看到.debug_*都是除錯資訊的section，每個section代表不同型別的除錯資訊，表2-1介紹不同型別除錯資訊。

表格2‑1除錯資訊型別說明

3      Gdb使用除錯資訊

Gdb中實現原始碼級別除錯，主要實現名稱、位置的對映。而這些資訊在gdb內部通過symbol來記錄的。Symbols按照一定的關係組合在一起，形成symbol table。在gdb中有三類符號表。

表格3‑1 gdb中的符號表

Gdb除錯主要依靠這三個符號表實現，minimal symtab比較簡單，也不屬於除錯資訊分析的範疇，本文不會對minimal symtab多加敘述。Partial symtab和full symtab的建立是根據除錯資訊完成的。下面gdb對除錯資訊的使用過程也是這麼兩張符號表的建立的過程。

3.1    Debug_info——PartialSymtab

3.1.1     Partial symtab簡介

在展開partial symbol相關的討論之前，我們先看看partialsymbol是什麼。

在gdb中使用structpartial_symbol，來描述一個partial symbol，其中包含的資訊如下表所示。

表格3‑2 struct partial_symbol

Partial symbol以一定的規則組合在一起，形成partial symtab，gdb中以source file為單位，每個source file對應一個struct partial_symtab，一個objfile中的所有的partial_symtab組成一個連結串列。Partial symtab中只記錄該file中static型別的和global型別的一些符號。Struct partial_symtab的包含的資訊如下表所示。

表格3‑3 struct  partial_symtab

3.1.2     Partial_symtab建立流程

              本節介紹讀取除錯資訊，建立partialsymtab的流程。

              gdb就可以根據此使用一些file_static和global的符號，進行一些基本的原始碼級別的除錯了。

該過程在gdb將symbol file新增進來的時候進行。不同的objfile格式，實現的函式不一樣。針對Elf檔案，具體呼叫函式elf_symfile_read()函式完成。該函式主要做了兩件事情：1，讀取objfile中.symtab、.dynsym(如果有的話)的符號，建立起minimal symtab；2，讀取分析除錯資訊，建立partial symtab。下面具體分析此流程，流程如下圖所示。

圖 3‑1 elf_symfile_read流程

              從上述流程圖中我們看到會有stab除錯資訊的部分，這裡做一個說明。除錯資訊分為很多中有dwarf格式、stab格式等。除錯資訊在gcc將原始檔編譯成彙編檔案時會加入除錯資訊，而彙編器在將彙編檔案彙編成目標檔案。彙編器輸入的彙編檔案分為兩類：一類是gcc編譯生成的，裡面會含有除錯資訊；另一類是使用者hand-write彙編檔案，其中不帶除錯資訊。而彙編器也有除錯相關引數：-gstatbs和-gdwarf-2，分別用來為彙編檔案生成stabs格式和dwarf格式的除錯資訊。

              本文的重點是介紹dwarf除錯資訊的讀取和解析，該過程在dwarf2_build_psymtabs（）函式中完成，該函式的基本流程如圖2-3，

圖 3‑2 dwarf2_build_psymtabs函式流程

3.1.3     以cu為單位解析除錯資訊

              Gdb中以cu為單位對除錯資訊進行分析，建立partial symtab，下面展開具體分析。

通過上述分析可知，首先會把.debug_info中的內容讀入到記憶體中，然後獲取每個cu的除錯資訊的header資訊，最後逐個cu來分析.debug_info中的內容，以append的方式建立起partial symbol table。對於dwarf除錯資訊分析的細節在函式process_psymtab_comp_unit()中，下面到這個函式中跟蹤分析

圖 3‑3 process_psymtab_comp_unit流程

通過對process_psymtab_comp_unit（）的跟蹤分析，發現並不會把所有的DIE對應的符號都新增到partialsymbol table中。而是選取了一些file static和global的符號。流程分析中可以看出來，怎麼去讀取DIE中的資訊構建partial symbol的、選取哪些DIE、怎麼把symbol新增到list中，這個核心的過程都在load_partial_dies()函式中。接下來跟蹤分析這一過程，如圖所示。

圖 3‑4 load_partial_dies()流程

              至此，將該cu的main file的.debug_info中的所有DIE都分析完，選取了合適的加入到partial symbol table中。

但是我們知道，main file中可能include很多file，有header file，也可能是c file。Partial_symtab是一個sourcefile一個的。這裡，我們不是為所有的included file都建立一個partial_symtab，而是選取如果該cu行號資訊中，有用到該included file（該file中有函式定義），那麼就需要為該included file建立一個struct partial_symtab。。那該cu有哪些included files？這些included files有沒有在行號資訊中用到？這些通過怎樣分析得到呢？接下來就要分析.debug_line section的行號資訊了。process_psymtab_comp_unit（）函式的最後一步呼叫dwarf2_build_include_psymtabs()完成這個工作。

              在分析此函式之前，先簡單回顧一下.debug_line中行號資訊的格式。行號資訊是實現source-level debug的重要部分，完成目標地址和原始碼之間的對映關係。.debug_line中的行號資訊也是以cu為單位組織存放的，行號資訊理論上應該是一張很大的表，每個地址一個表項，記錄當前的行號、檔名、路徑名等資訊。但是為了儲存空間的問題，我們將行號資訊進行編碼，.debug_line中儲存的實際上是一系列的編碼過的opcode，每個cu的行號資訊叫做一個opcode program。每個cu的opcode program之前都會有一個header，這個header記錄了一些重要的資訊。比如，該cu的行號資訊的長度，header的長度，dwarf的版本，以及一些opcode相關的初始資訊。此處，我們需要關注的是header中還包含兩張表“The Directory Table”和“The File Name Table”。分別記錄了該編譯單元的include的路徑表和included file names表。

              下面，跟蹤分析dwarf2_build_include_psymtabs()的具體流程，如所示。

圖 3‑5 build include psymtab流程

              每個source file一個structpartial_symtab，objfile中維護這麼一個鏈，included file依賴於其main file（dependency可以不止一個）。

              至此，根據dwarf除錯資訊讀入partialsymbol table的工作已經完成，在接來下的除錯過程中如果需要更多的除錯資訊，可以根據當前的partial symbol table讀入full symbol table。可以根據對應struct partial_symtab的read_symtab（）函式指標指向的函式完成full symtab的讀入，dwarf2_psymtab_to_symtab()函式。Read_symtab_private指標指向當讀入fullsymtab中需要的資料，struct dwarf2_per_cu_data。具體過程在3.2中介紹。

3.2    partial_symtab+dies——full_symtab

Gdb的source-leveldebugging的原理就是符號名、位置、值的處理，這些資訊都由symbol提供，gdb的除錯過程實質上是對符號的處理，而gdb中維護的symbol資訊是從除錯資訊中解析出來的。在3.1Section中介紹的partial symbol是提取部分除錯資訊獲得的，而除錯過程中需要更多的更完整的符號資訊時，我們就需要獲取full symbol table。Full symtab是partial symtab的擴充套件，符號的資訊更全，新增的符號也更多。同樣的，full symtab也是以source file為單位的。下面舉例介紹。

3.2.1     When is full_symtab needed?

Gdb除錯過程中最常見的操作是設定斷點，比如 “break main”，那麼我們需要知道字串main對應的symbol，進而知道該symbol的location，那麼我們就可以在這個位置placebreakpoint了。那麼我們現在已知的條件是：1，main字串、2，當前的pc、3，一堆待解析的除錯資訊，下面開始整個使用除錯資訊建立symbol的流程。

在本例中，分析的是dwarf和stabs除錯資訊格式混用的情況，彙編器對於使用者輸入的彙編檔案，使用stabs除錯資訊（至少有行號資訊）。第一個編譯單元是stabs的格式，而要查詢的main並不在該編譯單元中，所以需要global symbol查詢，然後根據psymtab_to_symtab(pst)讀入main符號所在cu的full symtab。

3.2.2     Full_symtab 建立流程

Psymtab_to_symtab(pst)是一個函式介面，根據不同格式的除錯資訊會呼叫不同的函式實現。Here，dwarf2_psymtab_to_symtab()函式來實現該過程。下面具體分析這個fullsymtab的讀入過程。

圖 3‑6 psymtab_to_symtab流程

       簡要描述該流程就是：根據pst找到cu，讀取cu的所有的dies，根據讀入的dies構建該cu的full symtab。現在我們關注後兩步，怎麼讀取所有的dies，以及怎樣根據讀入的cu的dies構建好full symtab。

3.2.2.1              Full dies的讀入

首先，考察一下如何讀入這個cu的所有的dies，如圖所示

圖 3‑7 full除錯資訊dies的讀入

該部分的邏輯很簡答，就是根據die儲存的邏輯結構，把該cu的所有的die從.debug_info中讀出來，然後構建出這個一個die tree，儲存在記憶體中。

3.2.2.2              分析dies，構建full symtab

現在我們獲取了整個cu的所有的dies，那麼接下來分析這些除錯資訊，為該cu構建好full symtab。該部分工作由函式process_full_comp_unit()完成，該函式的流程如圖所示。

圖 3‑8分析dies流程

該流程包括三個步驟，一個是建立symtab之前的初始化工作，一個是對除錯資訊die的處理建立symtab，最後是一些善後工作。在初始化過程中看到的幾個全域性變數做一一說明，如下表所示。

表格3‑4 full_symtab構建相關全域性變數說明

該流程的核心是process_die()，該函式是一個switch函式體，針對不同TAG的die，採取不同的處理方式。先總體介紹一下對不同的die的處理函式。如下表所示。

表格3‑5 不同型別die的處理

下面是對DW_TAG_subprogramdie處理時，為function建立block的流程，該cu中的所有block會組成一個連結串列，由pending_blocks全域性變數指

圖 3‑9 為function建立block

Process_die()函式用來處理引數指定的die及其child，首先處理的是tag_cu的die，然而該cu的所有的die都是tag_cu的die的children。所以在過程中會遞迴呼叫process_die()函式把該cu的其它的dies也處理掉。那麼我們檢視下對tag_cudie的處理函式read_file_scope()函式的流程。

圖 3‑10 read_file_scope()流程

可以看到process_die()函式流程走完，該cu的所有的die都會被處理，這時候相應的symbol都已經建立並且記錄下來了，行號資訊也解析讀取了，巨集資訊也相應的解析了。至此除錯資訊的分析工作大部分已經完成。

上述流程圖中把symbols的建立以及行號資訊的分析詳細介紹了，下面單獨介紹一下巨集資訊的解析。巨集資訊放在.debug_macinfo section中，也是以cu為單位存放的，但是隻有一系列的entry，沒有為每個cu建立一個巨集資訊的header，在DW_TAG_complile_unit中會有DW_AT_macro_info屬性表徵該cu的巨集資訊在.debug_macinfo中的位元組偏移。巨集資訊的格式很簡單。

在開始分析巨集資訊的解析流程之前，我們先了解下gdb中幾個在巨集資訊解析中重要的資料結構，如下表所示。

表格3‑6 巨集資訊相關資料結構

資料結構背景介紹完成之後，下面開始巨集資訊的分析流程，如下圖所示，

圖 3‑11 巨集資訊解析流程圖

巨集資訊的entry中無非就是四類操作，檔案的開始，檔案的結束，巨集的define，巨集的undefine。該cu的巨集資訊解析完成後，我們最後得到的是一個macro_table，裡面包含了巨集的splay tree，file的inclusion tree。該macro_table由全域性變數pending_macros指向。

              Prcess_die()的流程至此結束，symtab建立的流程只剩下最後一步，symtab_end()來完成最後的一些資訊收集和掃尾工作。如下圖所示，

圖 3‑12 end_symtab()流程圖

              至此該cu的full symtab就已經完全建立，為對該cu的除錯提供了完整的資訊。