<var id="fnfpo"><source id="fnfpo"></source></var>
<rp id="fnfpo"></rp>

<em id="fnfpo"><object id="fnfpo"><input id="fnfpo"></input></object></em>
<em id="fnfpo"><acronym id="fnfpo"></acronym></em>
  • <th id="fnfpo"><track id="fnfpo"></track></th>
  • <progress id="fnfpo"><track id="fnfpo"></track></progress>
  • <tbody id="fnfpo"><pre id="fnfpo"></pre></tbody>

  • x
    x

    RTEMS任務級別調試技術研究

    發布時間:2010-3-29 22:19    發布者:李寬
    關鍵詞: RTEMS , 調試 , 級別 , 技術 , 任務
    引言

    調試一直是嵌入式系統開發的難題。開發者往往直接面對嵌入式開發硬件進行開發,就算目標嵌入式環境中引入了操作系統,其功能通常也有一定的限制,不能方便地進行調試。而且,引入嵌入式操作系統的過程中的調試問題也很棘手。遠程調試是解決此類問題的首選方案。

    RTEMS操作系統是當今應用廣泛的開源實時操作系統。本文將以RTEMS操作系統為討論背景,介紹RTEMS操作系統環境下,如何使用GDB來完成系統的任務級調試工作。

    1 RTEMS操作系統簡介

    RTEMS,即實時多處理器系統(Real Time Executivefor Multiprocessor Systems),是一個開源的實時嵌入式操作系統。它最早用于美國國防系統,現在它在航空航天、軍工及民用領域都有著廣泛的應用。

    從結構上來看,RTEMS是微內核搶占式實時系統。圖1顯示了RTEMS操作系統的基本結構。圖中白色部分為RTEMS操作系統的硬件支持部分 (Board SupportPackage),它包括了硬件抽象代碼、硬件設備驅動代碼和操作系統啟動代碼;疑糠譃镽TEMS內核以及系統提供給應用程序的 API。在具體應用場景中,圖中所有系統模塊都被編譯成一個靜態連接庫,用戶編寫的應用程序和RTEMS庫靜態鏈接成一個整體,形成運行在目標環境的鏡像文件。應用程序只將需要的系統支持模塊鏈接進來,最大程度地縮小了可執行鏡像的大小。



    此外,RTEMS十分簡潔,力求實時性。它不支持虛擬內存,整個系統內核以及應用程序運行在共同的平板內存空間之上。因此,RTEMS鏡像文件的運行可以看作是一個大型的、處理時鐘中斷的裸板程序。

    2 GDB遠程調試

    GDB全稱GNU symbolic debugger。在大多數情況下,在UNIx或者Linux環境下使用GDB調試本機程序,GDB通過waitpid、ptrace等系統調用對被調試進程進行監查和控制。這種調試模式很常見,但它只是GDB調試的一種特殊情況:GDB本身的運行環境和被調試程序的運行環境恰巧是同一個。在有些情況下,被調試程序運行環境下可能無法方便地運行GDB,那么遠程調試就會派上用場。

    2.1 遠程調試中程序的交互途徑

    如圖2所示,GDB和被調試程序運行于不同的環境中。在GDB加載了和被調試程序對應的調試信息之后,用戶可以通過它對被調程序進行源代碼級調試。用戶向 GDB下達調試命令,GDB將用戶的調試命令翻譯、打包,通過串口或者網絡接口發送至被調試程序端的GDB—SERVER。GDB—SERVER將接收到的調試命令包解包,并將其表達的調試命令實施于被調試程序。如果需要,還應將命令執行結果通過遠程通信返回給GDB端。



    2.2 GDB與GDB—SERVER

    GDB和GDB—SERVER之間的數據通道上傳輸的信息遵循GDB Remote Serial Protocol。它是一種簡潔的、基于ASCII的協議。每一個RSP報文由ASCII符號“$”開頭,由“#”將報文內容和兩個字節的報文校驗隔開,如下所示:



    接收方對報文進行校驗,如果校驗成功,回復ASCII字符“+”,否則回復“一”。

    通過RSP傳輸的命令種類很多,比較常用的羅列于表1中。當用戶使用GDB遠程調試程序時,GDB將用戶的命令翻譯成若干條RSP命令的序列下達給GDB —SERVER。GDB—SERVER對命令進行實施,并回復運行結果。作為一個能實現基本調試功能的GDB—SERVER,至少需要實現表1中列出的命令。



    2.3 GDB—SERVER與被調試程序

    GDB—SERVER和被調試程序之間的交互方式就比較靈活了,在沒有虛擬內存管理的環境中可以使用指針直接訪問被調試程序的內存,而在引入了嵌入式操作系統的環境中可以使用系統調用實現。GDB—SERVER是GDB調試命令的實施者,依照GDB的調試基本需求,GDB—SERVER和被調試程序之間的交互方式只要能夠完成表1中列出的操作就可以了。

    3 傳統STUB調試模式概述

    GDB —STUB是嵌入在被調試程序中的小段程序,它肩負了和GDB通信并執行GDB調試命令的重任?梢哉fGDB—STUB是輕量級的GDB—SERVER。它代碼量很少,在RTEMS啟動初始化階段,將它以軟中斷處理程序的身份嵌入到RTEMS之中,成為RTEMS的一部分。當被調試程序運行到這個特殊的軟中斷時,STUB程序獲得運行的權力,和GDB進行遠程通信,執行調試命令,直到收到被調試程序繼續執行的命令,STUB恢復被調試程序的執行,如圖3所示。



    由于它和被調試程序融為一體,所以它可以直接訪問被調試程序的內存地址,查詢或者修改被調試程序內存空間的值。

    此方法將RTEMS系統看作一個嵌入式裸板程序,可以在源碼級別對整個RTEMS系統進行調試?梢韵胂,此時GDB根本不知道被調試程序是一個操作系統,一旦STUB獲得了執行機會,整個RTEMS系統進入暫停狀態,無論系統中運行的是應用還是系統內核本身。而調試系統本身遠遠沒有調試系統中應用程序的需求量大,在調試應用的時候,希望只是被調試的任務暫停,系統中其他任務不受我們調試行為的影響。下文將介紹RTEMS任務級別的GDB遠程調試方法。

    4 面向任務的RTEMS調試

    為了實現面向RTEMS任務的調試手段,將調試相關服務抽象成RTEMS任務和RTEMS中斷處理程序。這樣調試服務也將作為任務被RTEMS系統調度,當沒有調試需求的時候,這些任務處于不可調度狀態,不影響整個系統的運行。調試服務由以下三部分組成:

    初始化任務,負責整個RTEMS調試服務的啟動。

    命令處理任務,與GDB交互,執行命令,并回復執行結果。

    事件處理程序,獲取任務中斷信號,通知GDB被調試任務的狀態。

    這三部分的邏輯關系如圖4所示。



    4.1 調試任務說明

    (1)初始化任務

    初始化任務負責整個RTEMS調試服務的啟動。它首先對GDB和調試服務之間的通信路徑(串口或者網絡接口)進行初始化,然后建立命令處理任務,并將事件處理程序與對應的軟中斷掛接起來。在初始化一切正常的情況下,初始化任務的歷史使命徹底完成,它將自己刪除。

    (2)命令處理任務

    命令處理任務由初始化任務建立。當GDB有命令到來的時候它被喚醒,接受命令,執行命令,并將執行結果發送回GDB。

    現在整個調試服務都建立在RTEMS任務機制之上,又由于RTEMS支持POSIX接口規范,在“執行命令”階段使用ptrace之類的系統調用來控制被調試任務是更好的選擇。它可以降低調試服務和硬件平臺的關聯性,易于調試服務的移植和擴展。

    在GDB發送繼續執行命令(c命令或者s命令)的時候,命令處理程序對全局信號量DebugEvent進行一次V操作,使被調試程序成為可調度任務。

    (3)事件處理程序

    事件處理程序不是一個任務,而是一個軟中斷處理程序。當被調試程序遇到斷點(軟中斷命令)的時候,處理器會轉到事件處理程序上來。在STUB調試模式中,基本所有調試功能都在這個程序中完成,這就阻礙了RTEMS系統以及系統中其他任務的運行。

    現在,事件處理程序只是報告GDB被調試程序中斷發生,然后將對全局信號量DebugEvent進行一次P操作,使被調試任務進入不可調度狀態。

    在此要注意軟中斷的性質,它不同于真正的外部中斷。用操作系統接口的概念來類比將更容易理解:當遇到一個軟中斷的時候,RTEMS將堆棧轉換成對應任務的系統堆棧,但是此時仍然處于任務上下文當中,那么當然也就可以在事件處理程序中睡眠。

    4.2 調試任務同步關系

    通過任務優先等級和信號量來維持調試系統任務之間的同步關系。

    首先,初始化任務和命令處理任務擁有相同的優先級——RTEMS中最高的優先級,其他所有應用的優先級都要低于此優先級,不能等于。這樣就保證了GDB送來調試命令的時候,命令處理任務能夠及時反應。

    其次,使用全局DebugEvent信號量來控制被調試任務的調度狀態。每次遇到斷點,被調試任務進入事件處理程序(可看作是一個系統調用陷入)中,阻塞在事件處理程序的P操作之上。當命令處理任務收到被調試任務繼續執行的命令時,對DebtagEvent信號量進行V操作,使被調試任務重新可調度。

    最終調試服務的運行狀態是:初始化任務在系統運行之初就刪除了自己;在GDB不發送命令的時候,命令處理任務處于阻塞態,此時,RTEMS系統正常運行。當被調試任務遇到斷點的時候,被調試任務阻塞在對Debu—gEvent信號量的P操作上,GDB得到被調試任務狀態變化的通知,用戶開始下達調試命令。 GDB通過RSP傳送給被調試端的每一條命令,都會將命令處理任務喚醒。命令處理位務迅速執行命令,將執行結果回復,然后重新進入到阻塞狀態,等待下一條命令的到來。如果收到被調試任務繼續執行的命令,命令處理任務對DebugEvent信號量進行V操作,使被調試任務得以繼續被調度。

    4.3 其他相關問題

    第一個斷點:為了不讓被調試任務一下子運行到結尾(不給調試服務任何的執行機會),需要在被調試任務的開頭以手工修改代碼的方式加入第一個斷點。斷點往往就是一個指定的軟中斷匯編指令(以i386為例,軟中斷對應匯編指令“int 3”)。此時,用戶可以通過GDB遠程下達調試命令,對被調程序進行正常調試,并設置后繼的斷點?烧{試代碼范圍:首先,調試服務中用到的代碼都是不可以被設置斷點的,這樣會引起調試服務的遞歸調用,系統會直接崩潰。其次,要避免在多個任務重入的代碼中設置斷點,這樣有可能多個任務向GDB匯報遇到了斷點,產生混亂。

    結語

    本文對RTEMS操作系統的調試手段進行了探討。其中STUB調試方式比較成熟,可以參考GDB源碼中的./gdb/i386一stub.c來理解 STUB的工作方式。在此基礎上,本文提出了面向任務的調試方式,在思路上延續STUB的路線,將調試服務分散到RTEMS任務和RTEMS軟中斷服務中去,實現了簡單實用的面向任務的RTEMS調試手段。

    參考文獻

       1. 王欽騫.羅克露 嵌入式系統調試器的研究與實現 2006
       2. 查看詳情
       3. 李獻霞.孟小鎖 嵌入式系統源碼調試器GDB的遠程通信 [期刊論文] -微處理機2006(1)
       4. 黃紅燕.史烈 GDBstub 的剖析與改進 [期刊論文] -電子技術應用2006(5)

    作者:北京航空航天大學 黨建勛  尚利宏  李紅兵
    來源:單片機與嵌入式系統應用  2009 (3)
    本文地址:http://www.portaltwn.com/thread-9972-1-1.html     【打印本頁】

    本站部分文章為轉載或網友發布,目的在于傳遞和分享信息,并不代表本網贊同其觀點和對其真實性負責;文章版權歸原作者及原出處所有,如涉及作品內容、版權和其它問題,我們將根據著作權人的要求,第一時間更正或刪除。
    您需要登錄后才可以發表評論 登錄 | 立即注冊

    廠商推薦

    • Microchip視頻專區
    • EtherCAT®和Microchip LAN925x從站控制器介紹培訓教程
    • MPLAB®模擬設計器——在線電源解決方案,加速設計
    • 讓您的模擬設計靈感,化為觸手可及的現實
    • 深度體驗Microchip自動輔助駕駛應用方案——2025巡展開啟報名!
    • 貿澤電子(Mouser)專區

    相關視頻

    關于我們  -  服務條款  -  使用指南  -  站點地圖  -  友情鏈接  -  聯系我們
    電子工程網 © 版權所有   京ICP備16069177號 | 京公網安備11010502021702
    快速回復 返回頂部 返回列表
    精品一区二区三区自拍图片区_国产成人亚洲精品_亚洲Va欧美va国产综合888_久久亚洲国产精品五月天婷