簡(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è)》先別急著翻目錄它到底能幫你解決哪幾類問(wèn)題如果你正在做車載儀表、工業(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ā)指南。適合誰(shuí)適合已經(jīng)寫過(guò) C 代碼、理解操作系統(tǒng)基本概念但第一次在 QNX 上做交叉編譯、寫資源管理器或調(diào)實(shí)時(shí)性問(wèn)題的嵌入式工程師。它解決的核心問(wèn)題是讓你知道在 Neutrino 這個(gè)微內(nèi)核架構(gòu)下哪些做法是符合其設(shè)計(jì)哲學(xué)的哪些是從 Linux 思維帶過(guò)來(lái)的壞習(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ī)的庫(kù)版本對(duì)齊問(wèn)題。但一旦項(xiàng)目進(jìn)入多平臺(tái)構(gòu)建階段自宿主就不夠用了——你不可能給每一塊目標(biāo)板都配一套完整的編譯環(huán)境。交叉開發(fā)是更常見的做法。宿主機(jī)上裝 QNX Momentics 工具鏈通過(guò)串口、以太網(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)工具鏈、庫(kù)路徑和目標(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 # 通過(guò) 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)鏈接把庫(kù)代碼直接塞進(jìn)可執(zhí)行文件好處是部署簡(jiǎn)單不依賴目標(biāo)機(jī)上的庫(kù)版本壞處是二進(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)一步共享庫(kù)只有在真正被引用時(shí)才從存儲(chǔ)介質(zhì)加載到內(nèi)存。手冊(cè)里給了RTLD_LAZY和RTLD_NOW的對(duì)比前者適合啟動(dòng)階段只用到少量庫(kù)函數(shù)的程序后者適合對(duì)確定性要求極高的實(shí)時(shí)任務(wù)——因?yàn)閼薪壎◣?lái)的首次調(diào)用延遲是不可預(yù)測(cè)的。// 運(yùn)行時(shí)加載共享庫(kù)的典型寫法 #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表示庫(kù)中的符號(hào)不會(huì)被后續(xù)加載的庫(kù)解析到。如果你希望多個(gè)模塊共享同一個(gè)庫(kù)實(shí)例要用RTLD_GLOBAL。實(shí)際項(xiàng)目中我見過(guò)有人用dlopen加載插件結(jié)果插件里又依賴了主程序已經(jīng)加載的另一個(gè)庫(kù)因?yàn)橛昧薘TLD_LOCAL導(dǎo)致符號(hào)找不到排查了半天。手冊(cè)里對(duì)這幾個(gè)標(biāo)志位的組合有詳細(xì)說(shuō)明建議在寫插件框架之前先翻一遍。提示QNX 的共享庫(kù)搜索路徑由LD_LIBRARY_PATH和編譯時(shí)寫入的rpath共同決定。交叉開發(fā)時(shí)目標(biāo)機(jī)上的庫(kù)路徑和宿主機(jī)上的QNX_TARGET目錄結(jié)構(gòu)必須對(duì)應(yīng)否則會(huì)出現(xiàn)“編譯通過(guò)、運(yùn)行報(bào)找不到庫(kù)”的經(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)程之間通過(guò)消息傳遞通信。這種設(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()的用法以及文件描述符繼承的問(wèn)題。在 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ù)來(lái)控制繼承行為。// 使用 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ā)不必要的頁(yè)拷貝。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)占用不超過(guò)預(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可能不生效。我見過(guò)有人在主線程里設(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í)不要超過(guò) 250留出空間給系統(tǒng)線程。4. 中斷處理與堆內(nèi)存分析兩個(gè)最容易翻車的地方4.1 寫中斷服務(wù)程序ISR 里能做什么、不能做什么手冊(cè)第六章專門講中斷處理。在 Neutrino 里中斷服務(wù)程序運(yùn)行在中斷上下文不能調(diào)用任何可能阻塞的函數(shù)不能做浮點(diǎn)運(yùn)算不能訪問(wèn)可能引發(fā)頁(yè)錯(cuò)誤的用戶空間內(nèi)存。ISR 要做的只有三件事確認(rèn)中斷源、清除硬件中斷標(biāo)志、然后通過(guò)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 庫(kù)把問(wèn)題釘死手冊(cè)第七章的標(biāo)題很直接“Heap Analysis: Making Memory Errors a Thing of the Past”。它介紹了 QNX 的 malloc debug 庫(kù)可以通過(guò)設(shè)置環(huán)境變量MALLOC_DEBUG來(lái)啟用不同級(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 庫(kù)會(huì)改變內(nèi)存分配的行為某些對(duì)內(nèi)存布局有假設(shè)的代碼比如自己實(shí)現(xiàn)的內(nèi)存池可能會(huì)在調(diào)試模式下表現(xiàn)異常。如果開啟調(diào)試后出現(xiàn)奇怪的問(wèn)題先確認(rèn)是不是調(diào)試庫(kù)本身引入的副作用。5. 避坑與排查五個(gè)讓我加班到凌晨的 QNX 開發(fā)問(wèn)題5.1 現(xiàn)象程序在目標(biāo)機(jī)上跑不起來(lái)報(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 的庫(kù)目錄。實(shí)在不行先靜態(tài)鏈接一版確認(rèn)程序邏輯沒問(wèn)題再回頭解決動(dòng)態(tài)鏈接的路徑問(wèn)題。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)程上下文不能睡眠也不能訪問(wèn)可能觸發(fā)頁(yè)錯(cuò)誤的內(nèi)存。解決ISR 里只用InterruptAttach返回的sigevent通知線程所有打印和日志操作放到線程里做。如果非要在 ISR 里記錄信息用無(wú)鎖環(huán)形緩沖區(qū)把數(shù)據(jù)存下來(lái)線程醒來(lái)后再?gòu)木彌_區(qū)讀。5.4 現(xiàn)象程序運(yùn)行一段時(shí)間后 malloc 返回 NULL但系統(tǒng)內(nèi)存看起來(lái)還很多原因地址空間碎片化。QNX 的進(jìn)程地址空間是有限的頻繁分配釋放不同大小的內(nèi)存塊會(huì)導(dǎo)致碎片即使總空閑內(nèi)存足夠也找不到一塊連續(xù)的區(qū)域滿足分配請(qǐng)求。解決用 malloc debug 庫(kù)的統(tǒng)計(jì)功能查看分配模式。對(duì)于頻繁分配的小對(duì)象考慮用內(nèi)存池預(yù)分配。手冊(cè)里提到了“small block configuration”可以通過(guò)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è)備過(guò)濾就會(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 的廣播包通過(guò)。如果網(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 通過(guò) /proc 直接讀寫進(jìn)程地址空間QNX 的/proc文件系統(tǒng)和 Linux 的/proc長(zhǎng)得像但內(nèi)部機(jī)制完全不同。手冊(cè)第三章詳細(xì)列出了DCMD_PROC_*系列命令這些命令通過(guò)devctl接口發(fā)送到/proc/pid/as文件描述符上可以讀取和修改目標(biāo)進(jìn)程的寄存器、內(nèi)存、線程狀態(tài)。// 通過(guò) /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ī)的庫(kù)和符號(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來(lái)控制線程切換時(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í)序行為。如果問(wèn)題只在特定時(shí)序下復(fù)現(xiàn)GDB 可能會(huì)讓問(wèn)題消失。這種情況下用/proc文件系統(tǒng)做非侵入式觀察或者在代碼里埋日志點(diǎn)比直接下斷點(diǎn)更可靠。從那以后我每次在 QNX 上開新項(xiàng)目都會(huì)先把編譯模式、庫(kù)鏈接方式和線程調(diào)度屬性這三樣確認(rèn)一遍再開始寫業(yè)務(wù)代碼。因?yàn)檫@三個(gè)地方一旦選錯(cuò)后面調(diào)實(shí)時(shí)性問(wèn)題時(shí)根本分不清是代碼邏輯的鍋還是配置的鍋。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取