今天要研究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)这个语句出现的问题了，果然和我的猜想一样。
就这样，问题搞定啦：）
后记：
有一位读者受到文章启发，针对5.3.4版本做出了对应的调整。社区的互动感觉还是蛮神奇的，放上链接，有需要的可以参考一下：
//www.greatytc.com/p/67d9baabd318
