許多開發人員都認為Ruby調試器是不存在的。這實際上是一個錯誤的觀念。那么Ruby調試器到底起到一個什么樣的作用，下面我們將會為大家做一個詳細的解讀。有些人說這是Ruby的一個問題。其他人則試圖將所謂的缺少調試工具解釋為智慧之舉和良好風格。#t#

這些觀點都是誤解。Ruby明明是有調試工具的——實際上有很多。讓我們來看一看這些現有的工具，包括調試GUI、調試器實現和各種Ruby實現中的調試支持。

什么是調試器？

首先，讓我們搞清楚“調試器”實際上涉及了哪些東西？

調試的GUI和接口

當然了，交互式調試器最重要的部分——至少對于用戶來說——是用戶接口。用戶可以使用Ruby調試器的命令行接口，例如和Ruby標準庫一起提供的Rubinius調試器。它顯然可以用來調試代碼，只不過設置斷點或查看運行狀態會比較麻煩。

IDE雖然有時在Ruby世界中不太受推崇，但它無疑令調試變得更簡單了——畢竟，IDE就是集成開發環境。集成對于調試來說很重要，而IDE正是把代碼編輯和調試工具整合在一起了。你可以在源代碼編輯器中直接管理斷點——而不用記下代碼的行號，進入命令行調試器中，然后手工設置斷點。在IDE中，諸如基于行的單步調試之類的功能也更加實用，可以正確的找到所打開的文件的棧結構和所在行。

帶有嵌入式腳本支持的IDE還允許對腳本進行調試。例如 ，Eclipse的EclipseMonkey擴展支持用JRuby寫成的腳本。由于這些腳本和Eclipse IDE都運行在同一個JVM上，由此調試器實例便可以被訪問和控制了。

調試器協議還是連接到后端

把像IDE這樣的調試器用戶接口和調試器后端連接起來的一個簡單方法是：使用命令行接口，并通過標準的stdin/stdout/stderr流來進行控制。這樣，編輯器或者IDE的調試器支持就可以控制調試器，同時也讓用戶管理斷點變得更加方便了。

另外一個方法是采用線路（wire）協議，它允許通過某種模式的進程通訊（IPC），現在一般是通過TCP/IP來連接到調試器。基于網絡的協議還允許GUI和調試器分布在不同的機器上，也就是說可以使用本地的用戶接口來對遠程機器進行調試。

基于文本的或者至少基于文檔的簡單調試協議也允許使用任何語言來編寫調試進程腳本。實際上，連接到Ruby調試器和打開telnet一樣簡單。debug-commons和DBGp命令的協議就是由單行字符串和XML應答構成的。

VM支持還是調試后端

為了支持斷點等功能，語言運行時至少得提供監視和控制執行的支持。可以簡單地像Ruby的跟蹤（tracing）功能一樣：在一行Ruby代碼執行之前，Ruby調試器會調用一個叫做set_trace_func的回調函數。傳過去的參數包括即將執行的那行代碼的環境信息，比如行號，所屬文件的名字和所屬的類等等。

這些信息就足以實現斷點功能了：在一個斷點注冊表里面檢查文件名和行號，看看是否被注冊了。 當遇到一個斷點時，執行就被掛起，只要不從回調中返回即可——Ruby運行時只能在回調返回后才能繼續運行。基于這些，就可以實現單步調試等功能了。 雖然使用跟蹤功能可以實現一個調試器，但是在執行每一行之前都要先執行跟蹤回調，顯然太慢了。理想地解決方案是僅在執行有斷點的行時才引發斷點處理。

運行時可以通過修改已加載的代碼來實現此功能——不論是AST還是操作碼（opcodes）——在有斷點的行上。有些語言的運行時提供了內建的調試支持，與執行機制整合在一起。Java和.NET的二進制代碼都提供調試信息（即從文件和行到字節代碼位置一個映射），讓內建的調試支持能使用這些信息來進行調試。

在Java世界中，例如，JVM配合JVM工具接口（JVM TI）一起實現了這個功能以及用來連接到JVM的Java調試線路協議（JDWP）。 還有一個方法是Rubinius調試器所使用的，它使用可訪問和可修改的Ruby調試器代碼中的操作碼（Rubinius把Ruby源代碼先編譯成操作碼然后再執行）。通過把一個一般操作碼替換成一個特殊操作碼來設置一個斷點，而這個特殊操作碼則用來掛起當前進程并通知調試堆棧中的高層。 通過設置大量的基礎體系和管理數據結構以供語言來訪問，語言本身就可以用來建立調試機制。