簡(jiǎn)介《QNX實(shí)時(shí)操作系統(tǒng)編程手冊(cè)》是面向QNX Neutrino 6.5.0開發(fā)者的權(quán)威技術(shù)指南由QNX Software Systems Limited出版適合具備一定操作系統(tǒng)原理與編程基礎(chǔ)的嵌入式工程師、實(shí)時(shí)系統(tǒng)開發(fā)者及高校相關(guān)專業(yè)學(xué)習(xí)者用于系統(tǒng)掌握QNX環(huán)境下的系統(tǒng)級(jí)與應(yīng)用級(jí)開發(fā)方法。資源包共1個(gè)文件為PDF格式大小約1.61MB內(nèi)容涵蓋進(jìn)程模型與線程調(diào)度、內(nèi)存與文件系統(tǒng)管理、網(wǎng)絡(luò)通信、靜態(tài)與動(dòng)態(tài)鏈接、運(yùn)行時(shí)加載、自主機(jī)與交叉編譯模式以及gdb調(diào)試、libmudflap內(nèi)存檢測(cè)等診斷技術(shù)并強(qiáng)調(diào)代碼可移植性與標(biāo)準(zhǔn)遵循。手冊(cè)對(duì)優(yōu)先級(jí)范圍、就緒隊(duì)列、阻塞與搶占機(jī)制等核心概念均有細(xì)致講解目錄結(jié)構(gòu)清晰便于按主題查閱。目前已有1674人學(xué)習(xí)下載可作為日常開發(fā)參考與系統(tǒng)學(xué)習(xí)的實(shí)用資料。1. 拿到《QNX實(shí)時(shí)操作系統(tǒng)編程手冊(cè)》先別急著翻目錄它到底能幫你解決哪幾類問題如果你正在做車載儀表、工業(yè)控制器或者醫(yī)療設(shè)備這類對(duì)響應(yīng)時(shí)間有硬要求的項(xiàng)目大概率繞不開 QNX Neutrino。但很多人第一次接觸它時(shí)面對(duì)的是 Momentics IDE 里一堆陌生的編譯選項(xiàng)、/proc文件系統(tǒng)里看不懂的進(jìn)程節(jié)點(diǎn)以及一個(gè)和 Linux 完全不同的調(diào)度模型。這份《QNX實(shí)時(shí)操作系統(tǒng)編程手冊(cè)》針對(duì)的是 Neutrino 6.5.0它不是 API 字典而是一本從編譯鏈接、進(jìn)程線程模型、中斷處理到堆內(nèi)存分析的系統(tǒng)級(jí)開發(fā)指南。適合誰適合已經(jīng)寫過 C 代碼、理解操作系統(tǒng)基本概念但第一次在 QNX 上做交叉編譯、寫資源管理器或調(diào)實(shí)時(shí)性問題的嵌入式工程師。它解決的核心問題是讓你知道在 Neutrino 這個(gè)微內(nèi)核架構(gòu)下哪些做法是符合其設(shè)計(jì)哲學(xué)的哪些是從 Linux 思維帶過來的壞習(xí)慣。2. 編譯與鏈接從自宿主到交叉開發(fā)選錯(cuò)模式后面全是坑2.1 自宿主開發(fā)和交叉開發(fā)到底怎么選手冊(cè)第一章就把開發(fā)模式分成了自宿主和交叉開發(fā)兩條路。自宿主就是目標(biāo)機(jī)本身跑 QNX你在上面直接編譯、運(yùn)行、調(diào)試。這種方式適合早期驗(yàn)證和小規(guī)模調(diào)試因?yàn)椴恍枰渚W(wǎng)絡(luò)文件系統(tǒng)也不需要處理宿主機(jī)和目標(biāo)機(jī)的庫版本對(duì)齊問題。但一旦項(xiàng)目進(jìn)入多平臺(tái)構(gòu)建階段自宿主就不夠用了——你不可能給每一塊目標(biāo)板都配一套完整的編譯環(huán)境。交叉開發(fā)是更常見的做法。宿主機(jī)上裝 QNX Momentics 工具鏈通過串口、以太網(wǎng)或者調(diào)試代理把編譯好的二進(jìn)制推到目標(biāo)機(jī)。手冊(cè)里提到了三種交叉開發(fā)連接方式網(wǎng)絡(luò)文件系統(tǒng)、調(diào)試器直連、以及深度嵌入式場(chǎng)景下的獨(dú)立鏡像燒錄。我一般會(huì)建議新手先用網(wǎng)絡(luò)文件系統(tǒng)跑通一個(gè) Hello World因?yàn)檫@樣能最快確認(rèn)工具鏈、庫路徑和目標(biāo)機(jī)啟動(dòng)參數(shù)是否匹配。# 在宿主機(jī)上設(shè)置 QNX 目標(biāo)環(huán)境變量 export QNX_TARGET/path/to/qnx650/target/qnx6 export QNX_HOST/path/to/qnx650/host/linux/x86 export PATH$QNX_HOST/usr/bin:$PATH # 編譯一個(gè)最簡(jiǎn)單的測(cè)試程序 qcc -V gcc_ntox86 -o hello hello.c # 通過 qconn 推送到目標(biāo)機(jī)并運(yùn)行 qconn-tools push hello /tmp/hello這段腳本里QNX_TARGET指向目標(biāo)機(jī)的根文件系統(tǒng)鏡像目錄QNX_HOST是宿主機(jī)工具鏈的位置。qcc是 QNX 的編譯器包裝器-V gcc_ntox86指定了目標(biāo)架構(gòu)和編譯器變體。注意如果你的目標(biāo)板是 ARM 或者 AArch64這里要換成gcc_ntoarmv7或gcc_ntoaarch64le。推送到目標(biāo)機(jī)后別忘了給二進(jìn)制加可執(zhí)行權(quán)限QNX 的/tmp默認(rèn)掛載方式有時(shí)候不帶執(zhí)行位。2.2 靜態(tài)鏈接、動(dòng)態(tài)鏈接和運(yùn)行時(shí)加載的取舍手冊(cè)在“Using libraries”這一章把鏈接方式講得很細(xì)。靜態(tài)鏈接把庫代碼直接塞進(jìn)可執(zhí)行文件好處是部署簡(jiǎn)單不依賴目標(biāo)機(jī)上的庫版本壞處是二進(jìn)制體積大多個(gè)進(jìn)程同時(shí)跑的時(shí)候內(nèi)存里會(huì)有多份副本。動(dòng)態(tài)鏈接是默認(rèn)推薦但 QNX 的動(dòng)態(tài)鏈接器支持懶綁定和懶加載這兩個(gè)特性對(duì)啟動(dòng)時(shí)間敏感的場(chǎng)景很有用。懶綁定指的是函數(shù)第一次被調(diào)用時(shí)才解析符號(hào)地址而不是程序啟動(dòng)時(shí)一次性解析所有符號(hào)。懶加載更進(jìn)一步共享庫只有在真正被引用時(shí)才從存儲(chǔ)介質(zhì)加載到內(nèi)存。手冊(cè)里給了RTLD_LAZY和RTLD_NOW的對(duì)比前者適合啟動(dòng)階段只用到少量庫函數(shù)的程序后者適合對(duì)確定性要求極高的實(shí)時(shí)任務(wù)——因?yàn)閼薪壎◣淼氖状握{(diào)用延遲是不可預(yù)測(cè)的。// 運(yùn)行時(shí)加載共享庫的典型寫法 #include dlfcn.h void *handle dlopen(libmyfilter.so, RTLD_LAZY | RTLD_LOCAL); if (handle NULL) { fprintf(stderr, dlopen failed: %s\n, dlerror()); return -1; } // 獲取函數(shù)指針 int (*process)(void *, size_t) dlsym(handle, process_frame); if (process NULL) { fprintf(stderr, dlsym failed: %s\n, dlerror()); dlclose(handle); return -1; }這里RTLD_LAZY表示延遲綁定RTLD_LOCAL表示庫中的符號(hào)不會(huì)被后續(xù)加載的庫解析到。如果你希望多個(gè)模塊共享同一個(gè)庫實(shí)例要用RTLD_GLOBAL。實(shí)際項(xiàng)目中我見過有人用dlopen加載插件結(jié)果插件里又依賴了主程序已經(jīng)加載的另一個(gè)庫因?yàn)橛昧薘TLD_LOCAL導(dǎo)致符號(hào)找不到排查了半天。手冊(cè)里對(duì)這幾個(gè)標(biāo)志位的組合有詳細(xì)說明建議在寫插件框架之前先翻一遍。提示QNX 的共享庫搜索路徑由LD_LIBRARY_PATH和編譯時(shí)寫入的rpath共同決定。交叉開發(fā)時(shí)目標(biāo)機(jī)上的庫路徑和宿主機(jī)上的QNX_TARGET目錄結(jié)構(gòu)必須對(duì)應(yīng)否則會(huì)出現(xiàn)“編譯通過、運(yùn)行報(bào)找不到庫”的經(jīng)典翻車。3. 進(jìn)程、線程與調(diào)度Neutrino 的微內(nèi)核模型和 Linux 差在哪3.1 進(jìn)程模型一個(gè)應(yīng)用是一組進(jìn)程不是一個(gè)進(jìn)程手冊(cè)第二章開篇就點(diǎn)明了一個(gè)關(guān)鍵差異在 Neutrino 里一個(gè)應(yīng)用程序通常是一組協(xié)作的進(jìn)程而不是 Linux 那種“一個(gè)主進(jìn)程 fork 出一堆線程”的模型。每個(gè)進(jìn)程有自己獨(dú)立的地址空間進(jìn)程之間通過消息傳遞通信。這種設(shè)計(jì)的好處是故障隔離——一個(gè)進(jìn)程崩了不會(huì)拖垮整個(gè)應(yīng)用。代價(jià)是進(jìn)程間通信的開銷比線程間共享內(nèi)存要大。進(jìn)程創(chuàng)建有兩種方式fork()和posix_spawn()。手冊(cè)里專門有一節(jié)講fork()和forkpty()的用法以及文件描述符繼承的問題。在 QNX 上fork()之后子進(jìn)程會(huì)繼承父進(jìn)程的文件描述符但如果你在 fork 之前打開了消息連接或者共享內(nèi)存對(duì)象子進(jìn)程里的這些句柄狀態(tài)需要特別小心。我一般會(huì)建議在 fork 之前把不必要的 fd 關(guān)掉或者直接用posix_spawn()配合文件動(dòng)作參數(shù)來控制繼承行為。// 使用 posix_spawn 創(chuàng)建子進(jìn)程精確控制文件描述符繼承 #include spawn.h #include fcntl.h posix_spawn_file_actions_t actions; posix_spawn_file_actions_init(actions); // 子進(jìn)程里關(guān)閉不需要的 fd posix_spawn_file_actions_addclose(actions, STDIN_FILENO); // 把 stdout 重定向到日志文件 posix_spawn_file_actions_addopen(actions, STDOUT_FILENO, /var/log/child.log, O_WRONLY | O_CREAT | O_APPEND, 0644); char *argv[] { /usr/bin/myapp, -d, NULL }; pid_t pid; int ret posix_spawn(pid, /usr/bin/myapp, actions, NULL, argv, environ); if (ret ! 0) { fprintf(stderr, spawn failed: %s\n, strerror(ret)); } posix_spawn_file_actions_destroy(actions);posix_spawn_file_actions_addclose在子進(jìn)程執(zhí)行 exec 之前關(guān)閉指定的 fdaddopen則打開一個(gè)新文件并把它分配到指定的 fd 編號(hào)上。這種方式的確定性比 fork 之后手動(dòng)操作 fd 要好因?yàn)?fork 會(huì)復(fù)制整個(gè)地址空間在內(nèi)存緊張的嵌入式系統(tǒng)上可能觸發(fā)不必要的頁拷貝。3.2 線程調(diào)度優(yōu)先級(jí)范圍、FIFO 和輪轉(zhuǎn)到底怎么配Neutrino 的線程優(yōu)先級(jí)范圍是 0 到 255數(shù)值越大優(yōu)先級(jí)越高。手冊(cè)里有一張圖展示了五個(gè)線程的就緒隊(duì)列優(yōu)先級(jí)最高的線程永遠(yuǎn)排在隊(duì)首。調(diào)度策略有三種FIFO、輪轉(zhuǎn)和零星調(diào)度。FIFO 就是一旦線程開始運(yùn)行除非它主動(dòng)阻塞或者被更高優(yōu)先級(jí)線程搶占否則一直跑下去。輪轉(zhuǎn)是每個(gè)線程分配一個(gè)時(shí)間片時(shí)間片用完就放到同優(yōu)先級(jí)隊(duì)列的末尾。零星調(diào)度比較特殊它允許一個(gè)線程在指定周期內(nèi)占用不超過預(yù)算的 CPU 時(shí)間適合那些需要周期性執(zhí)行但又不能獨(dú)占 CPU 的任務(wù)。// 設(shè)置線程調(diào)度策略和優(yōu)先級(jí) #include pthread.h #include sched.h struct sched_param param; param.sched_priority 200; // 高優(yōu)先級(jí)但低于中斷處理線程 pthread_attr_t attr; pthread_attr_init(attr); pthread_attr_setschedpolicy(attr, SCHED_FIFO); pthread_attr_setschedparam(attr, param); pthread_attr_setinheritsched(attr, PTHREAD_EXPLICIT_SCHED); pthread_t tid; pthread_create(tid, attr, my_realtime_task, NULL);這里PTHREAD_EXPLICIT_SCHED很關(guān)鍵。默認(rèn)情況下新線程繼承創(chuàng)建者的調(diào)度屬性如果你不顯式設(shè)置這個(gè)標(biāo)志setschedpolicy和setschedparam可能不生效。我見過有人在主線程里設(shè)了 FIFO 優(yōu)先級(jí) 200然后創(chuàng)建的工作線程還是默認(rèn)的輪轉(zhuǎn)優(yōu)先級(jí) 10結(jié)果實(shí)時(shí)任務(wù)被后臺(tái)日志線程搶了 CPU查了半天才發(fā)現(xiàn)是繼承標(biāo)志沒設(shè)對(duì)。注意在 QNX 上中斷處理線程的優(yōu)先級(jí)通常高于普通應(yīng)用線程。如果你把應(yīng)用線程優(yōu)先級(jí)設(shè)到 255可能會(huì)和內(nèi)核中斷線程沖突導(dǎo)致系統(tǒng)響應(yīng)異常。手冊(cè)建議應(yīng)用線程優(yōu)先級(jí)不要超過 250留出空間給系統(tǒng)線程。4. 中斷處理與堆內(nèi)存分析兩個(gè)最容易翻車的地方4.1 寫中斷服務(wù)程序ISR 里能做什么、不能做什么手冊(cè)第六章專門講中斷處理。在 Neutrino 里中斷服務(wù)程序運(yùn)行在中斷上下文不能調(diào)用任何可能阻塞的函數(shù)不能做浮點(diǎn)運(yùn)算不能訪問可能引發(fā)頁錯(cuò)誤的用戶空間內(nèi)存。ISR 要做的只有三件事確認(rèn)中斷源、清除硬件中斷標(biāo)志、然后通過InterruptAttachEvent或者信號(hào)機(jī)制通知應(yīng)用線程去處理實(shí)際的數(shù)據(jù)。// 典型的中斷處理線程模型 #include sys/neutrino.h #include sys/siginfo.h // 中斷服務(wù)程序只做最小必要操作 const struct sigevent *isr_handler(void *arg, int id) { // 讀取硬件寄存器確認(rèn)中斷源 volatile uint32_t *status (volatile uint32_t *)0x48000000; if (*status 0x01) { // 清除中斷標(biāo)志 *status | 0x01; // 返回事件通知等待線程 return event; } return NULL; // 不是這個(gè)中斷源 } // 應(yīng)用線程實(shí)際的數(shù)據(jù)處理 void *interrupt_thread(void *arg) { int id InterruptAttach(IRQ_NUM, isr_handler, NULL, 0, 0); if (id -1) { perror(InterruptAttach); return NULL; } struct sigevent event; SIGEV_INTR_INIT(event); while (1) { InterruptWait(0, NULL); // 等待中斷事件 // 在這里做數(shù)據(jù)處理可以調(diào)用阻塞函數(shù) process_sensor_data(); } InterruptDetach(id); return NULL; }InterruptAttach把 ISR 掛到指定的中斷號(hào)上返回一個(gè)中斷 ID。InterruptWait讓線程阻塞直到 ISR 返回一個(gè)非 NULL 的sigevent。這種“上半部只確認(rèn)、下半部做處理”的模式是 QNX 推薦的做法。手冊(cè)里還提到了共享中斷的處理——多個(gè)設(shè)備共用一個(gè)中斷線時(shí)每個(gè) ISR 都要檢查自己的硬件狀態(tài)寄存器確認(rèn)是不是自己的中斷不是就返回 NULL。4.2 堆內(nèi)存錯(cuò)誤用 malloc debug 庫把問題釘死手冊(cè)第七章的標(biāo)題很直接“Heap Analysis: Making Memory Errors a Thing of the Past”。它介紹了 QNX 的 malloc debug 庫可以通過設(shè)置環(huán)境變量MALLOC_DEBUG來啟用不同級(jí)別的檢查。比如MALLOC_DEBUG3會(huì)啟用邊界檢查和填充字節(jié)校驗(yàn)每次 malloc 分配的內(nèi)存塊前后會(huì)加上保護(hù)字節(jié)free 的時(shí)候檢查這些字節(jié)有沒有被改寫。# 在目標(biāo)機(jī)上啟用 malloc 調(diào)試 export MALLOC_DEBUG3 export MALLOC_TRACE/tmp/malloc_trace.log ./my_application # 程序退出后查看報(bào)告 cat /tmp/malloc_trace.logMALLOC_DEBUG的級(jí)別從 0 到 7級(jí)別越高檢查越細(xì)但性能開銷也越大。級(jí)別 3 通常夠用能抓到緩沖區(qū)溢出和重復(fù)釋放。級(jí)別 7 會(huì)記錄每次分配的調(diào)用棧適合定位內(nèi)存泄漏但日志文件會(huì)膨脹得很快。我一般會(huì)在測(cè)試階段用級(jí)別 3 跑一輪壓力測(cè)試確認(rèn)沒有堆破壞之后再降到級(jí)別 1 做長(zhǎng)時(shí)間穩(wěn)定性測(cè)試。提示malloc debug 庫會(huì)改變內(nèi)存分配的行為某些對(duì)內(nèi)存布局有假設(shè)的代碼比如自己實(shí)現(xiàn)的內(nèi)存池可能會(huì)在調(diào)試模式下表現(xiàn)異常。如果開啟調(diào)試后出現(xiàn)奇怪的問題先確認(rèn)是不是調(diào)試庫本身引入的副作用。5. 避坑與排查五個(gè)讓我加班到凌晨的 QNX 開發(fā)問題5.1 現(xiàn)象程序在目標(biāo)機(jī)上跑不起來報(bào) “cannot execute binary file”原因交叉編譯時(shí)目標(biāo)架構(gòu)選錯(cuò)了。宿主機(jī)上qcc默認(rèn)可能用的是 x86 變體但目標(biāo)板是 ARM?；蛘叨M(jìn)制雖然架構(gòu)對(duì)了但動(dòng)態(tài)鏈接器路徑不對(duì)目標(biāo)機(jī)上找不到/usr/lib/ldqnx.so.2。解決用file命令確認(rèn)二進(jìn)制架構(gòu)qcc -V列出所有可用的編譯器變體。如果是動(dòng)態(tài)鏈接的程序檢查目標(biāo)機(jī)的LD_LIBRARY_PATH是否包含 QNX 的庫目錄。實(shí)在不行先靜態(tài)鏈接一版確認(rèn)程序邏輯沒問題再回頭解決動(dòng)態(tài)鏈接的路徑問題。5.2 現(xiàn)象線程優(yōu)先級(jí)設(shè)了但沒生效實(shí)時(shí)任務(wù)還是被延遲原因pthread_attr_setinheritsched沒有設(shè)成PTHREAD_EXPLICIT_SCHED新線程繼承了創(chuàng)建者的默認(rèn)調(diào)度屬性?；蛘呔€程雖然優(yōu)先級(jí)高但在等一個(gè)低優(yōu)先級(jí)線程持有的互斥鎖發(fā)生了優(yōu)先級(jí)反轉(zhuǎn)。解決創(chuàng)建線程前顯式設(shè)置繼承標(biāo)志。如果涉及互斥鎖使用pthread_mutexattr_setprotocol開啟優(yōu)先級(jí)繼承協(xié)議。QNX 的互斥鎖默認(rèn)支持優(yōu)先級(jí)繼承但需要顯式初始化屬性。5.3 現(xiàn)象ISR 里調(diào)用 printf 導(dǎo)致系統(tǒng)掛死原因printf內(nèi)部會(huì)調(diào)用malloc和文件 I/O這些操作在中斷上下文里是禁止的。中斷上下文沒有進(jìn)程上下文不能睡眠也不能訪問可能觸發(fā)頁錯(cuò)誤的內(nèi)存。解決ISR 里只用InterruptAttach返回的sigevent通知線程所有打印和日志操作放到線程里做。如果非要在 ISR 里記錄信息用無鎖環(huán)形緩沖區(qū)把數(shù)據(jù)存下來線程醒來后再從緩沖區(qū)讀。5.4 現(xiàn)象程序運(yùn)行一段時(shí)間后 malloc 返回 NULL但系統(tǒng)內(nèi)存看起來還很多原因地址空間碎片化。QNX 的進(jìn)程地址空間是有限的頻繁分配釋放不同大小的內(nèi)存塊會(huì)導(dǎo)致碎片即使總空閑內(nèi)存足夠也找不到一塊連續(xù)的區(qū)域滿足分配請(qǐng)求。解決用 malloc debug 庫的統(tǒng)計(jì)功能查看分配模式。對(duì)于頻繁分配的小對(duì)象考慮用內(nèi)存池預(yù)分配。手冊(cè)里提到了“small block configuration”可以通過mallopt調(diào)整小塊內(nèi)存的分配策略。5.5 現(xiàn)象Qnet 網(wǎng)絡(luò)通信在單機(jī)上正常多機(jī)部署后時(shí)通時(shí)斷原因Qnet 依賴節(jié)點(diǎn)描述符和 GNS 服務(wù)定位。多機(jī)環(huán)境下如果節(jié)點(diǎn) ID 沖突或者 GNS 廣播被網(wǎng)絡(luò)設(shè)備過濾就會(huì)出現(xiàn)服務(wù)發(fā)現(xiàn)失敗。手冊(cè)第五章和附錄 D 詳細(xì)講了 Qnet 的節(jié)點(diǎn)描述符和 GNS 配置。解決檢查每臺(tái)設(shè)備的節(jié)點(diǎn) ID 是否唯一確認(rèn)網(wǎng)絡(luò)設(shè)備允許 GNS 的廣播包通過。如果網(wǎng)絡(luò)環(huán)境不支持廣播改用靜態(tài)配置節(jié)點(diǎn)信息。對(duì)于可靠性要求高的場(chǎng)景手冊(cè)建議配置多條傳輸路徑做冗余。6. 進(jìn)階技巧用 /proc 文件系統(tǒng)和 GDB 做進(jìn)程級(jí)調(diào)試6.1 通過 /proc 直接讀寫進(jìn)程地址空間QNX 的/proc文件系統(tǒng)和 Linux 的/proc長(zhǎng)得像但內(nèi)部機(jī)制完全不同。手冊(cè)第三章詳細(xì)列出了DCMD_PROC_*系列命令這些命令通過devctl接口發(fā)送到/proc/pid/as文件描述符上可以讀取和修改目標(biāo)進(jìn)程的寄存器、內(nèi)存、線程狀態(tài)。// 通過 /proc 讀取目標(biāo)進(jìn)程的寄存器信息 #include sys/procfs.h #include devctl.h int fd open(/proc/1234/as, O_RDWR); if (fd -1) { perror(open /proc/pid/as); return -1; } procfs_status status; int ret devctl(fd, DCMD_PROC_STATUS, status, sizeof(status), NULL); if (ret EOK) { printf(PID: %d, state: %d, num_threads: %d\n, status.pid, status.state, status.num_threads); } // 讀取線程的通用寄存器 procfs_greg greg; greg.tid status.tid; // 當(dāng)前線程 ID ret devctl(fd, DCMD_PROC_GETGREG, greg, sizeof(greg), NULL); if (ret EOK) { printf(PC: 0x%lx, SP: 0x%lx\n, greg.gpr[REG_PC], greg.gpr[REG_SP]); } close(fd);DCMD_PROC_STATUS獲取進(jìn)程的整體狀態(tài)包括線程數(shù)量、當(dāng)前運(yùn)行的線程 ID、進(jìn)程狀態(tài)標(biāo)志。DCMD_PROC_GETGREG讀取指定線程的通用寄存器greg.gpr數(shù)組的索引取決于目標(biāo)架構(gòu)x86 和 ARM 的寄存器編號(hào)不同。這種方式的優(yōu)勢(shì)是你不需要在目標(biāo)進(jìn)程里嵌入任何調(diào)試代碼只要進(jìn)程還在運(yùn)行就可以從外部觀察它的狀態(tài)。6.2 GDB 調(diào)試 QNX 目標(biāo)從啟動(dòng)會(huì)話到多線程斷點(diǎn)手冊(cè)附錄 B 是 GDB 的完整命令參考但真正實(shí)用的部分在第二章的“Diagnostics and debugging”。交叉調(diào)試 QNX 目標(biāo)需要三個(gè)東西目標(biāo)機(jī)上運(yùn)行qconn或者pdebug宿主機(jī)上有對(duì)應(yīng)的 GDBntox86-gdb或ntoarm-gdb以及正確的連接參數(shù)。# 在目標(biāo)機(jī)上啟動(dòng)調(diào)試代理 qconn # 在宿主機(jī)上啟動(dòng) GDB 并連接 ntoarm-gdb ./my_application (gdb) set sysroot /path/to/qnx650/target/qnx6 (gdb) target qnx 192.168.1.100:8000 (gdb) upload ./my_application /tmp/my_application (gdb) set nto-executable /tmp/my_application (gdb) runset sysroot告訴 GDB 去哪里找目標(biāo)機(jī)的庫和符號(hào)文件這個(gè)路徑要和目標(biāo)機(jī)的實(shí)際文件系統(tǒng)對(duì)應(yīng)。target qnx建立到目標(biāo)機(jī)qconn服務(wù)的連接默認(rèn)端口 8000。upload把宿主機(jī)上的二進(jìn)制推到目標(biāo)機(jī)set nto-executable指定目標(biāo)機(jī)上的執(zhí)行路徑。連接成功之后GDB 的斷點(diǎn)、單步、查看變量這些操作和本地調(diào)試沒有區(qū)別。多線程調(diào)試時(shí)info threads列出所有線程thread n切換當(dāng)前線程。QNX 的 GDB 擴(kuò)展支持set nto-thread-event來控制線程切換時(shí)是否暫停所有線程。對(duì)于實(shí)時(shí)性敏感的程序我一般會(huì)把這個(gè)選項(xiàng)關(guān)掉避免調(diào)試器暫停某個(gè)線程時(shí)影響其他線程的時(shí)序。注意用 GDB 調(diào)試實(shí)時(shí)線程時(shí)斷點(diǎn)命中會(huì)導(dǎo)致整個(gè)進(jìn)程暫停這可能改變程序的時(shí)序行為。如果問題只在特定時(shí)序下復(fù)現(xiàn)GDB 可能會(huì)讓問題消失。這種情況下用/proc文件系統(tǒng)做非侵入式觀察或者在代碼里埋日志點(diǎn)比直接下斷點(diǎn)更可靠。從那以后我每次在 QNX 上開新項(xiàng)目都會(huì)先把編譯模式、庫鏈接方式和線程調(diào)度屬性這三樣確認(rèn)一遍再開始寫業(yè)務(wù)代碼。因?yàn)檫@三個(gè)地方一旦選錯(cuò)后面調(diào)實(shí)時(shí)性問題時(shí)根本分不清是代碼邏輯的鍋還是配置的鍋。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取