今天要研究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)
这个语句出现的问题了,果然和我的猜想一样。
就这样,问题搞定啦:)
作者:子达如何
链接:http://www.jianshu.com/p/3c49cf454502
來源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。