序言

今天有个旧同事问起标题这个问题，没想到都2022年了，这个问题还在困扰广州某些知名游戏公司。于是，把以前的文章翻了一下，转载到新的平台上。

原发表地址：my.oschina.net/dourgulf/bl…

原文章正文如下

今天要研究 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.jianshu.com/p/67d9baabd…

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

序言

原文章正文如下

授之以渔的环节