跟大神請教 - rexzhao－IT工程師數位筆記本

文章出處

我們是win32的服務器然后用的cocos的客戶端 cocos編譯的win32程序跟android兩個不同平臺的程序

然后那創建人物的時候會下發一個int64 也就是longlong的字段 win32沒問題但是android就會出現崩潰。。

大神：“win32 跟 arm……字序一樣嗎？”

那又如何檢查自序那？

大神：”我能想到的最快最土的辦法就是，把一個 int64 看成 char[8]，然后打印出來“

崩潰如圖

fatal siganl 7（SIGBUS）at

哦，SIGBUS……
大神
這個可能不是 pack 的問題
大神
pack 也無法保證
大神
如果是 SIGBUS 的話，我理解系統可能希望 sBuf+index-sizeof ( __int64 ) 這個地址是一個對齊在 64 位的地址

如果 sBuf 里全都是 64 位數據的話，問題倒也不大，但是如果你還有 GetInt32，GetChar 之類的接口，不按照 8 字節對齊的協議去修改 index 的話，可能有些 cpu 就受不了了——我知道 MIPS 有這說法，ARM 還真不了解

那只能避免使用int64？

大神

沒關系，一般 RISC 都還會有 unaligned 指令集的吧……

大神

沒關系，一般 RISC 都還會有 unaligned 指令集的吧……

__int64 GetInt64 ( char* sBuf, int& index, unsigned int nBufferLen )
{
__int64 n;
index += sizeof ( __int64 );
memcpy(&n, sBuf+index-sizeof ( __int64 ), sizeof(__int64));
return n;
}; 雖然沒有考慮字序 Byte Order 的問題這么處理希望 memcpy 中的指令對操作數的要求可以是 unaligned 的

看了log.txt得出結論不過異常原因基本上八九不離十了：code 1 (BUS_ADRALN)，我猜 ADRALN 就是 Address Alignment 之類的縮寫，肯定是這個出問題了

fault addr 776a2db3 這句很要命，這個地址充其量就對齊在 1 字節上吧，或者說根本沒對齊……

大神

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html

你可以抽空看看這個，這是 ARM 編譯器對未對齊指針的優化，可能會造成干擾

是的，我知道在 RISC 的 memcpy 實現中，最常見的做法就是用 unaligned 指令處理頭尾非對齊的地址，然后用 aligned 指令處理中間對齊的部分——對齊的操作數性能會好很多

你可以瞅瞅 lib 庫的編譯優化選項，如果有任何選項有“把memcpy/memmov/memset優化為intrinsic”的話，那可能調用 memcpy 還是會崩，因為編譯器會直接把 memcpy 展開成 load/store 指令的，不會有任何函數調用。這種情況下，可以嘗試弄個函數指針指向 memcpy，然后你再去 call 函數指針——不知道這樣弄的話，會不會把編譯器弄傻，它就不去做 intrinsic 優化了

ps 總之最后按照大神的思路算是把問題解決了雖然我還是云里霧里的

文章列表