Introspector

影片 1

這是解釋 Introspector 專案的一系列影片記錄中的第一個。

我決定，簡單地自我介紹是解釋專案背景和目的的最佳方式。

這些影片將託管在 wikibooks.org/wiki/Introspector 上，但也釋出到 Youtube 和其他入口網站上。

這個影片應該能讓我的朋友和家人理解，也能讓其他程式設計師感興趣。

內容將分成模組，這樣人們就可以跳過不感興趣的材料。

我們將介紹 Introspector 專案的許多方面，併為學習一般計算奠定基礎。

我將解釋什麼是編譯器，什麼是程式語言，並嘗試包含計算機的基礎知識以介紹計算。

簡而言之，編譯器將人類編寫和可讀的指令翻譯成控制計算機的機器指令。

gcc 編譯器翻譯了 5 種不同的語言，包括 C、C++、Java、Fortran、Pascal 和 ADA，並將它們翻譯成基於 Windows 的英特爾機器、基於 Linux 的英特爾機器、執行在摩托羅拉處理器的舊款 Macintosh 機器以及地球上基本上所有的硬體的機器語言。

稍後，我們將從 gnu g++ 編譯器擴充套件到 gnu 工具，如 gnu bash shell 和 Linux 作業系統核心。

bash shell 將被介紹為一個編譯的 C 程式，然後是您使用的程式。

我們將介紹 bash 程式設計的基礎知識，因為它有自己的語言，並展示 bash 函式如何由 C 程式解釋和執行。

我們將展示 bash 如何使用 C 執行時庫函式來呼叫作業系統函式並控制硬體。

我們將建立基本程式，然後向您展示從編寫原始碼到編譯、連結、執行和除錯程式碼的所有步驟。我希望能夠讓人們感受到將計算機程式翻譯成執行系統所涉及的所有步驟。

一個影片將向您展示如何在 cygwin windows 上安裝 gcc 編譯器，並自行編譯其中的更改。

其他影片將向您展示如何應用補丁，如何除錯編譯器以及哪些型別的補丁可用。

其他影片將展示編譯器中可用的各種除錯選項和轉儲檔案。

我們將回顧編譯器的一些模組，解釋提供的函式、編寫它們的人以及它們的使用方法。

我們將逐步講解課程，解釋從編譯器提取資料的必要性，以及對 Introspector 需求的動機。

然後我們將進入 RDF 和語義網，作為編譯器圖的智慧表示。

稍後我們將介紹像 graphviz 這樣的視覺化工具以及圖表的處理方法。

感謝您的收聽，期待您的反饋。

Introspector 的管理概述

內省本質上是計算機世界中更為人知的反射。術語“intro”讓我們聯想到內部，向內部看，而不是反射，反射意味著鏡子。對我來說，內省意味著檢視程式的結構。這意味著檢視私有和內部資料，並賦予這些資料意義，因為我們知道它（在那一刻）。考慮到所有參與程式和計算機系統各個部分建立的人員，如果沒有訪問所有人的知識，我們就無法實現完全的內省。這意味著內省會有侷限性，但我們可以透過獲得足夠多的有關程式碼的資料集來破解它。

因此，內省是一種手段，當正確應用時，可以幫助破解軟體程式碼，並擷取程式內部隱藏和封裝的含義。

內省是一種方式、一種方法或過程，透過將資料收集器注入到擁有有關您的軟體的最多資訊的程式中，並以一種可理解的形式收集這些資訊，來打破資料隱藏和封裝的約定。

資料收集器的注入涉及修改現有程式，或者透過偵錯程式修改執行路徑。

如果只有二進位制可執行檔案，則可以應用此技術，因為我們可以對作業系統、shell 和動態連結器和載入器進行內省。我們可以對彙編處理工具進行內省並新增資訊。我們可以通過了解處理器來對執行進行內省，以進行分析。

如果無法訪問作業系統，也無法訪問工具鏈，則幾乎不可能在機器級別上應用內省。內省過程可以應用於人工操作員、控制檯和螢幕截圖，所有互動、所有輸入和輸出都被收集到系統中和從系統中收集。

整個想法是，收集到的這些資料可以與其他系統在外部收集的其他資料進行交叉引用。交叉引用是理解和豐富資料的關鍵，這是資訊獲取和豐富過程。

完整的內省過程需要資訊才能發揮作用。

我們只關注免費/開源軟體，因為它是我們擁有足夠公開資訊來處理的唯一軟體。

讓我們從定義 GNU Linux 作業系統是如何設定的開始。

使用測試用例，我們可以記錄函式的輸入和預期輸出。透過彙編和資料流分析，我們可以瞭解資料上發生的各種操作型別。我們可以跟蹤變數的使用位置和方式。透過原始碼，我們可以自動解碼二進位制檔案。透過變更控制日誌，我們可以自動記錄原始碼。透過郵件列表，我們可以理解有關原始碼變更的討論。如果給定一個 SourceForge 票證系統，我們也可以以一致的方式構建這些工件。現在，所有這些方面都為程式添加了資訊。但是，當我們瞭解有關編譯器如何處理原始碼的所有資訊時，我們也可以自動將所有這些資訊連線在一起。

Bash 是一種 shell，它也是一個程式。shell 與作業系統（核心）互動。shell 保護使用者免受核心內部的干擾。strace 可以幫助攔截對作業系統的呼叫。對作業系統的呼叫可以看作是從 shell 到核心再回來的線路。瞭解作業系統的使用情況及其資源（如記憶體和檔案系統）對於理解程式至關重要。作業系統的使用情況無法直接檢視。shell 的實現也是隱藏的。

完全理解與抽象理解：所有這些隱藏的資料都是為了完全理解所需的。然而，可以透過堅持使用介面來獲得抽象理解。我們可以構建一個處理的抽象模型。根據收集資料的深度，我們可以獲得更詳細的理解。處理器內部很難訪問。每個處理器都不同。公司竭盡全力保護晶片設計並將其保留給自己。這給了他們優勢。

我們可以假設，每個可用的工具都需要有其存在的目的，才能生存。工具的生存能力是可以思考和分析的。降低其他工具保護級別的工具可以被視為降低訪問成本。然而，這些工具本身也存在成本。我們可以用另一組較低的障礙取代一組較高的障礙，但障礙仍然存在。

問題必須被簡化，這需要決策。第一步涉及人類模式匹配。這也可以被編碼，但仍然存在成本。人們還需要消耗資源才能生存，因此不客觀。我認為，一個社會方面是，人們會保護自己的利益，以避免做任何會威脅其環境穩定的事情。學習某件事的成本是他們希望獲得回報的。如果生產或學習工具的成本很高，那麼就會人為地製造障礙，以確保其他人無法輕鬆地訪問它。這是資訊保護的關鍵問題之一。生產者收集的資源越多，他們用來保護自己的資源就越多。當一個系統崩潰成自身並開始保護自己作為生存系統時，將會出現一個臨界點。

技術中存在著如此之多的問題，這一事實本身就意味著只有那些得到支援的問題才能生存。為了獲得支援，它們需要有一個明確的生存能力模型。

程式實際上是一組彙編指令，也可以分析每條指令都以一串位元組編碼。我們可以分析每個位元組的資訊並獲取有關它的資訊。

然而，為了理解這些資訊，我們需要將它們與從其他系統獲得的資訊聯絡起來。這需要在許多不同的系統之間進行通訊。通訊很困難，因為它們之間通常有許多不同的障礙。

透過分析機器，我們能夠看到執行路徑如何將它們連線起來。然而，為了做到這一點，我們需要有一組可以理解的測試。理解測試可能只意味著我們可以將測試用例對映到我們也理解的規範上。規範將被分成人類可以理解的部分。規範的語言也可以由語言工具解析，這將為我們提供一個包含識別符號的圖結構，這些識別符號可以對映到測試中找到的東西。

因此，理解可以定義為將關於測試執行獲得的資料圖完全對映到從規範中提取的資料圖。

我們首先定義一種方法來描述相互連線的圖層。每一層將從不同的工具中提取。然而，每一層都將用一種通用語言描述。RFD 的圖。

層本身就是一個程式，可能的圖型別總數非常大。這意味著測試用例將代表所有可能的圖資料的一小部分。重點是這些圖之間的連線和對映。

程式也不總是有效地工作，因此可能存在大量實際上不需要解決測試用例本身的處理。假設一個配置檔案會標記真正執行的處理路徑。

給定一個大型測試用例，我們可以然後尋找與較大測試用例匹配的小型測試用例的重疊部分。這將使我們能夠將大型圖分解成更小的子圖。

然後，我們還可以斷言所有這些工作都是為了特定目的而完成的。這個目的是被理解的，它限制了問題的範圍。我們需要理解這個範圍，以防止浪費資源。

我們可以透過理解人類解決問題所需的努力來迭代地定義系統。我們需要為他們提供有效工作的工具。

binutils 允許我們處理二進位制程式，原始碼和二進位制檔案之間存在關係，它是透過編譯器建立的。理解程式的原始碼可以理解編譯器處理的程式。編譯器由 shell 執行。在偵錯程式中設定斷點允許在除錯或檢查程式時檢查變數。你很容易被資訊淹沒。可以使用附加到斷點的指令碼將資訊收集到檔案或流中。工具可以用於處理收集的資訊以使其有意義。我們經常需要顯示從依賴項中收集的圖以理解它。圖結構對於人類來說很自然，RFD 基於圖。

最初的動機

作者 James Michael DuPont 描述了他對該程式的最初動機

最初的想法來自我對邏輯程式設計和程式生成器的研究。我曾試圖在青少年時期學習 Turbo Prolog，但從未完全掌握它。然而，我喜歡閱讀程式設計手冊，並且做了一些示例程式。對我來說，問題是我沒有從邏輯上理解其含義的概念，而更像是把任天堂遊戲塞進插槽的孩子。資料庫斷言是讓我感到困惑的部分，我不明白這些語句本身也是物件。

從擁有所有圖形介面的 DBASE V 開始，我很快就能熟練地建立資料庫。然後我也做了一些 DBASE III 的工作。早在 80 年代後期，RAD 就流行起來。FoxPro、Paradox 以及 Alpha4 和 Zachary 等其他環境對我來說至關重要。

RAD 互動式程式生成器和編輯器使用結構化的資料模型，允許程式設計師快速解決程式。有意義的匯入和匯出功能，再加上遠端網路檔案訪問和鎖定，是你建立互動式人員工作組所需的全部功能。

這些是我在設計該程式時腦海中所設想的概念的原始模型。這是在檢視 Introspector 專案時要牢記的模型。我使用這些工具為我家人中的商界人士解決問題。

在設計該程式時，我最初對程式實現的理解有限，並且專注於實際問題解決，這一點應該牢記。

現在，當我們編寫文件時，很難識別所有從程式設計師思維中流入文件的資料流。

然而，我們應該認為，我們有可能意識到我們當前的處境，並希望擺脫單調的處境。將心理流壓縮成更緊湊的形式並執行寫入操作是一個原子任務。我們可以將資料流視為隨著時間推移而倒塌的紙牌屋。然後，將符號寫入鍵盤上的輸出是最終的行動提交。然後，我們可以在另一個階段將該符號作為輸入讀回來。將紙牌屋重新搭建在一起需要的不僅僅是紙牌，這就是模型需求顯而易見的地方。模型基本上是你解碼訊息所需的所有資料。對於計算機來說，這就是它執行一條位元組指令的時刻。因此，該指令的模型將是能夠將其追溯到系統中某個時間點的某個外部模型所需的所有資料。

從這種模型中生成的程式將在檔名、變數名、函式名，甚至在文字常量、註釋以及其他各種使用者資料部分中包含對其生成模型的回溯引用。給定這樣的使用者空間模型，我們可以為每個程式宣告賦予一個含義。含義是在應用程式模型中定義的。

Introspector 的目的不是在任何時候為所有人提供所有資料，而是按需提供有關軟體程式的結構化資料，以幫助你快速解決問題。想法是，你必須從你只能部分訪問的系統中獲取資訊；使用自省過程，你可以透過建立攔截器物件來提取來自處理程式的工具的資料，這些攔截器物件可以掛鉤到正在執行的程序並捕獲任何進出程式中的某個點的資料。

程式的執行點可以定義為程式的指令指標。給定一個測試特定功能的測試用例，我們將能夠將給定的輸入檔案對映到模型位置。

我們可以將此 wiki 視為規範。wiki 頁面每個版本都可以視為一種資源。該版本的每個詞都可以用作索引。使用這種索引模式，我們可以用維基百科定義程式的所有部分。

示例

假設有一個程式的實現，它由某個文件指定。這在某個主機上的某個程序中執行。

我們可以透過其偏移量來定義輸入資料中的一個點。這是對模型的引用。只需要一個暫存器來引用儲存在陣列中的模型。

只有透過選擇和定義一個正式的觀點，你才能從編譯器獲得的資料洪流中得到任何意義。

它的引導想法是使用 GCC 的一個版本，該版本使用內建樹轉儲程式的修改版本，將關於 AST 的列印語句轉換為 wikipedia:資源描述框架格式中的即時資料，透過 wikipedia:Redland API。

狀態

以下是一些關於 gcc 介面 Introspector/GccCpp 的資訊。

圖的表示

已經進行並存在各種實驗，使用針對編譯器圖最佳化的底層後端表示，以及使用特殊 wikipedia:資料結構 “冰塊” 進行更高速度的資料傳輸的實驗。冰塊是壓縮資料立方體，是一組有效地描述編譯器圖的向量。

資料直接編譯到程式中，因此資料在程式啟動時載入。這不允許更改資料。那是 2003 年。

後來，在 2005 年 1 月，我使用 C 建立了更緊湊的圖形表示，以及使用它們的演算法。這是一個好的開始。它將圖形儲存為固定長度的記錄，可以從檔案系統中以塊的形式載入。

目標

對於本地使用：最終目標將能夠在需要時生成一個共享物件，該物件將為在該機器上載入生成圖形的最緊湊和最快的表示。我們還可以使用核心轉儲，因為圖形資料儲存在中性格式中。

對於傳輸：如果你想匯出一個圖形，那麼將它儲存為 RDF/XML 將是最佳選擇。

資料庫

已經構建了 Postgres 介面，儲存收集的圖形。第一個版本的資料庫結構直接基於節點型別。每個節點型別一個表。

此外，我使用 redland 建立了資料庫，它建立表以直接表示圖形。

使用資料庫表的問題是，你需要有以下約束

區域性性：在編譯器中一起出現的記錄應該以一種可以一起檢索的方式儲存。

記錄型別：記錄的型別及其擁有的欄位需要仔細選擇。記錄型別非常多。例如，函式宣告的型別非常多。

對資料庫表使用聯合型別並不總是明智的，將所有例項儲存在同一個表中。

Perl 介面

收集的資料

第一個自省樣本是從 gcc wikipedia:抽象語義圖收集的。

整合

所有這些工具都處於分離狀態，尚未整合。

層

我們要做的是瞭解系統的各個層。

Introspector/Compiler/Input Stream
Introspector/Compiler/Lexical Tokens
Introspector/Compiler/Parse Tree
Introspector/Compiler/AST
Introspector/Compiler/RTl
Introspector/Compiler/Dwarf
Introspector/Linker/Elf/Section
Introspector/Linker/Elf/Label
- Introspector/RDF
- 將 printfs 轉換為 rdf 發射的 API
  - 每個 PrintF 的呼叫棧
  - 分析表示式中每個變數的資料流
- Introspector/Graph Layout
Introspector/Annotation
- Introspector/Annotation/DIA
- Introspector/Annotation/Doxygen

簡短介紹

Introspector/Project 的目標是構建 Introspector/Project/Goals，為 WG:Free_Software_and_Open_Source_software 和 Introspector/SourceCode 構建 Introspector/MetaData/Manipulation/Tools。

Introspector 是一種新的 Introspector/ToolChain，用於從 GnuCompilerCollection 和其他 FreeSoftware LanguageTools（如 PerlLanguage、CSharpLanguage、BashLanguage）中提取關於你的軟體程式的 Introspector/MetaData，並將其呈現給你，使你作為程式設計師的工作更輕鬆。使用可擴充套件樣式表之類的轉換，程式碼超程式設計將變得輕而易舉。正在開發將軟體資訊壓縮成圖形和 GUI 的代理。

該軟體是按照 GnuManifesto 的精神開發的自由軟體，它在賦予使用者自由方面具有革命性意義。

這些元資料包括編譯器、make & build 系統、savannah/sourceforge 專案管理和 debian 打包系統、CVS 更改以及 mailman 郵件列表軟體收集的有關你的軟體的所有資料。

範圍蔓延

Introspector 的範圍最初只是 GCC C 編譯器，但現在已擴充套件到包括從不同編譯器和直譯器（如 Perl、bison、m4、bash、C#、Java、C++、Fortran、objective-c、Lisp 和 Scheme）中提取元資料。將正式提交各種補丁，以允許 Introspector 以標準形式提取資料。

檔案格式

這些提取的元資料儲存在 ntriple rdf 檔案中，一個按程式執行、輸入檔案、宣告的函式或類以及自省的時間和日期分類的儲存庫。這些檔案是標準化的，可以透過 Redland RDF API 供 eulersharp、cwm、Java、Perl、C、C++ 等工具訪問。這些 rdf 檔案可以透過 redland 儲存介面併發訪問。

來源

元資料將從以下免費工具中提取

GCC 編譯器的抽象語法樹
DotGNU/PNET/CSCC 和 DotGNU/PNET/Ccompiler 的抽象語法樹
PerlInternals 介面
Bash Shell 將擴充套件到也將其物件轉儲到 Rdf 中（基於 BashDB）
BisonParseTree 以及 BisonRules BisonTokens
M4MacroLanguage
Debian-SF sourceforge 應用程式儲存庫 GForge
PhpLanguage
PythonLanguage
SilverSchemeLanguage

介面

我們正在為 FreeSoftware 構建 IntrospectorInterfaces，以允許各種應用程式處理這些元資料。

GUI 編輯器 Glade
圖形佈局工具 Vcg
圖表編輯器 Dia
文字編輯器 Emacs

內省定義

元資料操作工具

include

資料提取工具
資料表示
資料倉庫
資料視覺化工具
程式碼生成工具

Introspector GUI

包含以下介面

Emacs 介面
Bash 介面
Dia 介面

資料視覺化工具

includes

Vcg 介面
AutoDia 介面
Dia 介面支援。

資料表示

supports

N3、RdfFormat、EulerSharp、CWM、RedlandInterface、NtriplesFormat、PerlRdfLaces
XmlFormat
HtmlFormat
表格文字檔案格式

Introspector 本體

Introspector 本體工作已經準備好整合。

我已經建立了描述 gcc 編譯器節點的本體的更新版本。

以下是本體的各個方面

1. 在 tree.def 中定義的節點 2. 在 c、tree.h 中定義的資料結構 3. 在 tree-dumper.c 中轉儲的資料結構 4. 宏中定義的資料結構訪問方法 5. gcc 自身程式碼中樹的使用。

動態問題

樹的哪些方面用於構建編譯器本身。

樹的哪些方面用於定義樹。
樹的哪些方面用於填充樹。

覆蓋範圍

需要什麼測試程式碼來執行編譯器並執行所有程式碼路徑？需要哪些路徑來填充樹的所有方面？樹的哪些部分來自使用者資料？樹的哪些部分來自編譯器資料？

內建資料

編譯器本身內建了什麼資料？編譯器版本之間有什麼區別？

標準標頭檔案

標準標頭檔案建立了什麼資料？使用了哪些版本的標頭檔案？

最佳擬合本體

1. 從執行編譯器建立了哪些型別的記錄？

我們想了解從編譯器收集的真實資料的型別。我們希望看到每個出現的輸出資料配置的本體型別記錄。

理想情況下，我們將資料型別定義為透過編譯器的完整執行路徑，影響資料的每條指令都將記錄在型別歷史記錄中。

目前，我們收集出現的資料型別併為每個型別建立一個型別。這就是我所說的例項型別。

2. 每種資料型別都有哪些公共欄位

對於每種資料型別，每個欄位集都有一組子集，這些子集也出現在其他記錄中。我們計算欄位的最大公集並將其與例項型別相關聯。

警告： 在 OWL 中，定義了超集/子集關係，其中例項型別是更一般型別的超型別。為什麼

3. 哪些欄位是僅對資料排序的列表欄位？

4. 哪些欄位代表程式的含義？ 5. 哪些其他型別的記錄被欄位引用？ 6. 透過哪些欄位哪些其他記錄引用了什麼型別的物件？

請參閱 Protoge Reasoner API

推理器整合

我的目標是使用內建在 gcc 中的 fact++ 推理器，在一個程序中執行。

為了實現這一點，我們需要處理以下問題：

1. 何時向推理器提供資料

我們可以向推理器提供資料：

對於第一步，我們可以處理 gcc 的轉儲函式。
在編譯器中首次收集資料時。
在編譯完成後。
當用戶定義的程式碼被執行時觸發。
當在編譯外部的 RDF 中定義的使用者定義模式出現在程式碼中並被匹配時

我們希望能夠在常量摺疊階段處理資料

2. 向推理器提供哪些資料

我們可以根據以下內容建立記錄：

編譯器本身的資料結構。
資料轉儲函式，基於記錄型別。
使用者定義的程式碼，使用屬性標記需要哪些資料
使用 RDF 來描述要收集哪些資料

3. 如何處理推理器的結果

我們需要能夠將多次編譯執行的結果合併在一起
我們希望能夠影響編譯本身。建立新結構。
我們希望能夠定義在編譯期間執行的使用者程式碼（常量摺疊表示式），這些程式碼基於

從編譯器收集的常量資料。

我們希望生成新的程式碼，這些程式碼會被編譯和連結

資料提取

需要能夠

ExtractWiki
ExtractMbox
ExtractSavannah
ExtractCvs

使用者管理

資料倉庫需要一個使用者管理和宣告管理系統。

以下是 IntrospectedProjects 的示例。

另請參閱：相關專案相似名稱專案已使用專案受影響專案客人日誌

舊內容

以下是要編輯的章節

，例如：我們將首先分析一個相關的 c 檔案

當我們檢視以下連結時

http://introspector.sourceforge.net/2005/07/bary/doxygen/html/structgnode.html

這張圖片很好地概述了 gnode

http://introspector.sourceforge.net/2005/07/bary/doxygen/html/structdllist__coll__graph.png

以下是從 DWARF 資料中獲取的另一個示例

http://introspector.sourceforge.net/2005/07/unwind-introspector-0.1.1/src/doxygen/html/structpubname__struct__coll__graph.png

外部連結

Introspector 主頁

http://en.wikipedia.org/wiki/DOAP https://wikibook.tw/wiki/Reverse_Engineering http://en.wikipedia.org/wiki/Core_dump http://en.wikipedia.org/wiki/Introspector_%28program%29

另請參閱：AspectX、srcML、XWeaver