發表文章

Building Clang with openSUSE Tumbleweed + Virtual Box 6.0

圖片
很久沒有編譯怪物級的專案來折磨 CPU 和硬碟了。 基本上照著 Clang 文件 https://clang.llvm.org/get_started.html 就不會在 compilation 上運到奇怪問題,只有幾個細節需要調校一下: Virtual Box 的 storage controller 要開啟 Host I/O Cache ,不然很容易在大量 I/O 時遇到 Virtual Box 沒有反應,然後出現 Disk I/O 讀取錯誤: 00:39:53.953457 Console: VM runtime error: fatal=false, errorID=BLKCACHE_IOERR message="The I/O cache encountered an error while updating data in medium "ahci-0-0" (rc=VERR_IO_NOT_READY). Make sure there is enough free space on the disk and that the disk is working properly. Operation can be resumed afterwards" 不要編譯 libcxx ,Clang 教學文件雖然提到這是 optional ,但實際跑時會在 linker 階段炸出很多 undefined reference  (乍看下感覺是 linker 只使用了 C runtime 而漏了 C++ runtime) 使用 gold 作為 linker 而不是 gnu ld ,因為 ld 在工作階段會耗用過多 memory ,以我的實驗為例:即使已經設定了 8GB Ram 和 8GB swap 空間,仍然會遇到 ld 耗盡 memory 的問題。 [ 63%] Linking CXX shared library ../../lib/libLTO.so /usr/bin/ld: failed to set dynamic section sizes: Memory exhausted Let's Build 先 checkout llvm svn co http://llvm.org/svn...

Missing Process Argument

圖片
哈利波特有消失的密室,CreateProcess() 有消失的參數?! 有一次升級了產品的 common module 後,同事發現某個功能失效了,失效的原因是 process 收不到 creator 給它的參數,WTF ... 不過有 bug 就有文章,讓我們看下去。 命案現場 發生問題的程式碼如下: // Creator CreateProcess( app, arg ); // Createe int CALLBACK wWinMain( ..., wchar_t* pCmdLine, ... ) { // ... if ( nullptr == pCmdLine || L'\0' == *pCmdLine ) { return -1; } // ... } 而升級也只是把 wmain() 改成 wWinMain(),為什麼這樣的改動後, arg1 就消失了呢? Short Answer 這問題最簡單的答案就是:這是 Windows 的行為。 當年 WinMain() 作為 GUI 程序的進入點,勢必要進行一些轉型正義處理,所以丟掉 program name 就是第一步。 main() 和 WinMain() 都是 Windows 上兩個標準的 entry points 。但 WinMain() 的 lpCmdLine 會去掉 program name [1]。 int CALLBACK WinMain( _In_ HINSTANCE hInstance, _In_ HINSTANCE hPrevInstance, _In_ LPSTR     lpCmdLine, _In_ int       nCmdShow ); lpCmdLine [in] Type: LPSTR The command line for the application, excluding the program name. To retrieve the entire command line, use the GetCommandLine function. ...

在 github 專案使用 boost license

圖片
在 github 開 repo 時,會發現預設 license 列表中是沒有 boost license ,身為 C++ 和 boost 的支持者,是可忍,孰不可忍啊!還好這只是預設列表中沒辦法選取,想要使用 boost license 的話,可以將 license file commit 到 repo root 。 boost license 在 github 中被縮寫為 BSL-1.0 。 Reference add boost software license support#223 https://help.github.com/articles/licensing-a-repository/#choosing-the-right-license Boost Software License

Hidden Mismatched Calling Convention

圖片
一個使用錯誤 calling convention 卻沒有 crash 的故事⋯ 使用錯的 calling convention 進行 function call 往往會在 callee function return 後讓 caller 的 stack pointer 指向錯誤的位址,此時 caller 再透過 stack pointer 去讀寫資料就會產生錯誤;可能讀到錯誤值、寫到錯誤位置,若是使用的資料型別是 pointer 時,更是容易使用到非法位址,引發 access violation 。從高階語言來看,這類的資料讀取往往透過 local variables 使用, return statement 去產生。 但如果在 callee 返回後,caller 都沒有透過 stack pointer 去存取資料,是不是可以神不知、鬼不覺地隱藏這個錯誤呢?正甚者,當 caller function 返回時,stack pointer 還能被還原到正確值呢? 回顧一下在 x86 Windows 系統上常見的 calling convention ,在沒有進行 FPO 最佳化時大都帶有 function prologue 和 epilogue ,像是下面 callModuleFunc() 為例,它的 prologue 和 epilogue 如下: // main.exe 使用 module.dll 的程式碼 0:000> uf main!callModuleFunc main!callModuleFunc [...\code\main\mainentry.cpp @ 12]: ; prologue 12 001f1040 55 push ebp 12 001f1041 8bec mov ebp,esp 12 001f1043 83ec08 sub esp,8 ; ... main!callModuleFunc+0x72 [...\code\main\mainentry.cpp @ 30]: ; epillgue 30 001f10b2 8be5 mov esp,ebp 30 001...

Syntax Hightlight

Powered by SyntaxHighlighter #include &ltiostream&gt using namespace std; int main() { cout Powered by highlight.js #include &ltiostream&gt using namespace std; int main() { cout Powered by highlight.js, x86asm // main.exe 使用 module.dll 的程式碼 0:000> uf main!callModuleFunc main!callModuleFunc [...\code\main\mainentry.cpp @ 12]: ; prologue push ebp mov ebp,esp sub esp,8 ; ... main!callModuleFunc+0x72 [...\code\main\mainentry.cpp @ 30]: ; epillgue 30 001f10b2 8be5 mov esp,ebp 30 001f10b4 5d pop ebp 30 001f10b5 c3 ret

這個網誌中的熱門文章

Building Clang with openSUSE Tumbleweed + Virtual Box 6.0

Missing Process Argument

Syntax Hightlight