64位lua引擎如何支持32位luac编译出来的二进制字节码？

今天要研究wax的热更方案，重拾lua。面对64位lua的问题。阿里给出的方案是：分别编译。也就是说64位引擎只支持64位编译器生产的字节码。32位引擎只支持32位编译器产生的字节码。为此，阿里给出了一组编译脚本来解决这个问题，在我看来是小题大做了。
而且，这个方案有个小小的问题，那就是iOS应用目前还是一份代码同时编译arm64和arm32版本的（比如在iPhone 5上的APP安装得到的是32位的执行代码）。

我的解决办法是：直接修改一下lua的引擎就好了。
我们先来看为什么64位的引擎不能执行32位luac编译出来的字节码？

1. 第一个是加载头的时候

   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);。

2. 第二个地方是加载字符串的时候

   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)这个语句出现的问题了，果然和我的猜想一样。
就这样，问题搞定啦：）

作者：子达如何
链接：http://www.jianshu.com/p/3c49cf454502
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。