今天要研究wax的热更方案，重拾lua。面对64位lua的问题。阿里给出的方案是：分别编译。也就是说64位引擎只支持64位编译器生产的字节码。32位引擎只支持32位编译器产生的字节码。为此，阿里给出了一组编译脚本来解决这个问题，在我看来是小题大做了。
而且，这个方案有个小小的问题，那就是iOS应用目前还是一份代码同时编译arm64和arm32版本的（比如在iPhone 5上的APP安装得到的是32位的执行代码）。
我的解决办法是：直接修改一下lua的引擎就好了。
我们先来看为什么64位的引擎不能执行32位luac编译出来的字节码？
第一个是加载头的时候
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字节，在64位平台下是8字节。
修改的办法就是改成：*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的实现是这样的；
#define LoadVar(S,x) LoadMem(S,&x,1,sizeof(x))
它根据size的类型从缓冲区获得数据，原因同上，这里它取了8个字节的长度。而实际上32位luac编译产生字节码的时候，这个长度只用了4个字节来表示。
修改的办法也很简单，改成：int size;即可。
其实，lua这种做法不够地道，字节码格式本应该使用一种平台无关的格式来定义才是。
那么，怎么让luac编译产生一个平台无关的格式呢？简单修改一下luac的实现也是可以办到的。
首先，我们需要假定就用4个字节表示字符串长度。（当然啦，你也可以假定字符串的长度就是8字节，不过，因为大部分现存系统上的luac都是32位编译的，他们没有被修改之前，产生的字节码中，字符串的长度是用4字节表示的。）
然后，修改一下这个方法：
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);}}
如果你真正读懂了文章前面的部分，那么这里怎么改，应该很清楚了吧？
好了，重新编译出来的luac，无论你用32位方式编译，还是64位方式编译，最终得到的编译器（luac）编译的lua字节码，它都是能被上面修改过的引擎正确加载了。
再也不用折腾32位一个版本，64位一个版本了~。
我是怎么定位到这些需要修改的地方的呢？
首先，我们要有问题的环境，也就是一个64位编译出来的lua64运行引擎，一个32位luac32编译出来的字节码luac32.out。
然后，我们用这个lua64执行这个luac32.out。这时候，会出现第一个错误信息：
bad header in precompiled chunk
在源代码里搜索这个错误提示，没有找到任何的结果。于是，把错误提示缩小一些（因为，我们平时也也经常写"error:%s"这样的日志输出）。直到查找"bad header"的时候，定位到一处函数了LoadHeader，不需要费太多力气大概就知道是最终这个函数luaU_header的结果出错导致的错误日志。好，第一处修改点就是这么定位出来的了。
继续跑测试用例，这次直接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
一看就是分配了一个非常非常大的内存了。这里，是需要一些灵感的，我自己看到这个错误的第一直觉是，加载字符串的时候出错了（不要问我为什么有这样的直觉，一般只有犯过错的人才有这样的直觉）。
这个错误没有什么日志信息可以辅助定位，大概只能单步调试一个函数一个函数的执行过去，看看到那个函数执行就报这个错了。
然后依次缩小范围。幸运的是，这只是一个很单纯的单线程程序，很快就可以定位到是LoadFunction-->f->source=LoadString(S)这个语句出现的问题了，果然和我的猜想一样。
就这样，问题搞定啦：）
作者：子达如何
链接：/p/3c49cf454502
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
