今天要研究wax的熱更方案，重拾l(fā)ua。面對64位lua的問題。阿里給出的方案是：分別編譯。也就是說64位引擎只支持64位編譯器生產(chǎn)的字節(jié)碼。32位引擎只支持32位編譯器產(chǎn)生的字節(jié)碼。為此，阿里給出了一組編譯腳本來解決這個問題，在我看來是小題大做了。
而且，這個方案有個小小的問題，那就是iOS應(yīng)用目前還是一份代碼同時編譯arm64和arm32版本的（比如在iPhone 5上的APP安裝得到的是32位的執(zhí)行代碼）。
我的解決辦法是：直接修改一下lua的引擎就好了。
我們先來看為什么64位的引擎不能執(zhí)行32位luac編譯出來的字節(jié)碼？
- 第一個是加載頭的時候
void luaU_header (char* h)
{
int x=1;
memcpy(h,LUA_SIGNATURE,sizeof(LUA_SIGNATURE)-1);
h+=sizeof(LUA_SIGNATURE)-1;
*h++=(char)LUAC_VERSION;
*h++=(char)LUAC_FORMAT;
*h++=(char)*(char*)&x; /* endianness */
*h++=(char)sizeof(int);
*h++=(char)sizeof(size_t);
*h++=(char)sizeof(Instruction);
*h++=(char)sizeof(lua_Number);
*h++=(char)(((lua_Number)0.5)==0); /* is lua_Number integral? */
}
其中的*h++=(char)sizeof(size_t);是平臺依賴的，size_t在32位平臺下是4字節(jié)，在64位平臺下是8字節(jié)。
修改的辦法就是改成：*h++=(char)sizeof(int);。
- 第二個地方是加載字符串的時候
static TString* LoadString(LoadState* S)
{
size_t size;
LoadVar(S,size);
if (size==0)
return NULL;
else
{
char* s=luaZ_openspace(S->L,S->b,size);
LoadBlock(S,s,size);
return luaS_newlstr(S->L,s,size-1); /* remove trailing '\0' */
}
}
size的類型是size_t，而LoadVar的實現(xiàn)是這樣的；
#define LoadVar(S,x) LoadMem(S,&x,1,sizeof(x))
它根據(jù)size的類型從緩沖區(qū)獲得數(shù)據(jù)，原因同上，這里它取了8個字節(jié)的長度。而實際上32位luac編譯產(chǎn)生字節(jié)碼的時候，這個長度只用了4個字節(jié)來表示。
修改的辦法也很簡單，改成：int size;即可。
其實，lua這種做法不夠地道，字節(jié)碼格式本應(yīng)該使用一種平臺無關(guān)的格式來定義才是。
那么，怎么讓luac編譯產(chǎn)生一個平臺無關(guān)的格式呢？簡單修改一下luac的實現(xiàn)也是可以辦到的。
首先，我們需要假定就用4個字節(jié)表示字符串長度。（當(dāng)然啦，你也可以假定字符串的長度就是8字節(jié)，不過，因為大部分現(xiàn)存系統(tǒng)上的luac都是32位編譯的，他們沒有被修改之前，產(chǎn)生的字節(jié)碼中，字符串的長度是用4字節(jié)表示的。）
然后，修改一下這個方法：
static void DumpString(const TString* s, DumpState* D)
{
if (s==NULL || getstr(s)==NULL)
{
size_t size=0;
DumpVar(size,D);
}
else
{
size_t size=s->tsv.len+1; /* include trailing '\0' */
DumpVar(size,D);
DumpBlock(getstr(s),size,D);
}
}
如果你真正讀懂了文章前面的部分，那么這里怎么改，應(yīng)該很清楚了吧？
好了，重新編譯出來的luac，無論你用32位方式編譯，還是64位方式編譯，最終得到的編譯器（luac）編譯的lua字節(jié)碼，它都是能被上面修改過的引擎正確加載了。
再也不用折騰32位一個版本，64位一個版本了~。
我是怎么定位到這些需要修改的地方的呢？
首先，我們要有問題的環(huán)境，也就是一個64位編譯出來的lua64運行引擎，一個32位luac32編譯出來的字節(jié)碼luac32.out。
然后，我們用這個lua64執(zhí)行這個luac32.out。這時候，會出現(xiàn)第一個錯誤信息：
bad header in precompiled chunk
在源代碼里搜索這個錯誤提示，沒有找到任何的結(jié)果。于是，把錯誤提示縮小一些（因為，我們平時也也經(jīng)常寫"error:%s"這樣的日志輸出）。直到查找"bad header"的時候，定位到一處函數(shù)了LoadHeader，不需要費太多力氣大概就知道是最終這個函數(shù)luaU_header的結(jié)果出錯導(dǎo)致的錯誤日志。好，第一處修改點就是這么定位出來的了。
繼續(xù)跑測試用例，這次直接crash了
malloc: *** mach_vm_map(size=8461182042380451840) failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
一看就是分配了一個非常非常大的內(nèi)存了。這里，是需要一些靈感的，我自己看到這個錯誤的第一直覺是，加載字符串的時候出錯了（不要問我為什么有這樣的直覺，一般只有犯過錯的人才有這樣的直覺）。
這個錯誤沒有什么日志信息可以輔助定位，大概只能單步調(diào)試一個函數(shù)一個函數(shù)的執(zhí)行過去，看看到那個函數(shù)執(zhí)行就報這個錯了。
然后依次縮小范圍。幸運的是，這只是一個很單純的單線程程序，很快就可以定位到是LoadFunction-->f->source=LoadString(S)這個語句出現(xiàn)的問題了，果然和我的猜想一樣。
就這樣，問題搞定啦：）
后記：
有一位讀者受到文章啟發(fā)，針對5.3.4版本做出了對應(yīng)的調(diào)整。社區(qū)的互動感覺還是蠻神奇的，放上鏈接，有需要的可以參考一下：
http://www.lxweimin.com/p/67d9baabd318
