luajt编译工具

A. 支持中文变量名的lua，在网上看到修改源码就可以让lua支持中文变量名。我学着修改了，可是改完后，

直接使用luajit就可以支持中文变量名。

--$./luajit-2.0.0-beta10
LuaJIT2.0.0-beta10--Copyright(C)2005-2012MikePall.http://luajit.org/
JIT:ONCMOVSSE2SSE3SSE4.
>你好="111"
>print(你好)
111
>

现在版本应该是支持lua5.1的。luajit的性能比lua5.1好多了。

B. lua脚本被luac编译之后，如何反编译或者反汇

标准的lua4.01 有“CFLuaDC”工具可以反编译。
标准的lua5 有 “DisLua”、“luadec” 两个工具可供选用。
－－－－－－－－以上三个工具在网上可搜索下载。
luajit 编译的luac 文件 尚无反编译工具。

C. Windows 下编译 LuaJIT

这里使用 Visual studio 自带的命令行工具来进行编译，所以需要安装好VS。

首先打开VS命令行工具。可以按 Win + S ，输入 prompt 来找到它。如图。

解压 LuaJIT 源码，并进入到解压目录 /src 下。输入 msvcbuild 开始编译。

看到 === Successfully built LuaJIT for xxxxx === 则是编译成功了。
在解压目录 /src 下可以找到编译生成的 luajit.exe 和 lua51.dll .

打开cmd。
如果没有添加环境变量则先定位到LuaJit安装目录。
输入 luajit +文件名 即可运行Lua脚本。
输入 luajit -b +Lua脚本+目标文件名，即可编译脚本。

D. 如何用 Valgrind 检测使用 LuaJIT FFI 过程中的内存泄漏

memcheck工具的使用方式如下:
valgrind --tool=memcheck ./a.out

从上面的命令可以清楚的看到, 主要的命令是valgrind，而我们想使用的工具是通过'-tool'选项来指定的. 上面的‘a.out’指的是我们想使用memcheck运行的可执行文件.
该工具可以检测下列与内存相关的问题 :
未释放内存的使用
对释放后内存的读/写
对已分配内存块尾部的读/写
内存泄露
不匹配的使用malloc/new/new[] 和 free/delete/delete[]
重复释放内存
注意: 上面列出的并不很全面，但却包含了能被该工具检测到的很多普遍的问题.
让我们一个一个地对上面的场景进行讨论:
注意: 下面讨论的所有测试代码都应该使用gcc并且加上-g选项(用来在memcheck的输出中生成行号)进行编译. 就想我们之前讨论过的 C程序被编译成可执行文件, 它需要经历四个不同的阶段.

ToB蓝波湾
翻译于 1 年 前
0人顶
顶 翻译的不错哦!

1. 使用未初始化的内存
Code :
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
char *p;

char c = *p;

printf("\n [%c]\n",c);

return 0;
}

在上面的代码中，我们尝试使用未初始化的指针 ‘p’.
让我们运行Memcheck来看下结果.
$ valgrind --tool=memcheck ./val
==2862== Memcheck, a memory error detector
==2862== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==2862== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for right info
==2862== Command: ./val
==2862==
==2862== Use of uninitialised value of size 8
==2862== at 0x400530: main (valgrind.c:8)
==2862==

[#]
==2862==
==2862== HEAP SUMMARY:
==2862== in use at exit: 0 bytes in 0 blocks
==2862== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==2862==
==2862== All heap blocks were freed -- no leaks are possible
==2862==
==2862== For counts of detected and suppressed errors, rerun with: -v
==2862== Use --track-origins=yes to see where uninitialized values come from
==2862== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)

从上面的输出可以看到,Valgrind检测到了未初始化的变量，然后给出了警告(上面加粗的几行(译者注：貌似上面没有加粗的)).
2. 在内存被释放后进行读/写
Code :
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
char *p = malloc(1);
*p = 'a';

char c = *p;

printf("\n [%c]\n",c);

free(p);
c = *p;
return 0;
}

上面的代码中，我们有一个释放了内存的指针 ‘p’ 然后我们又尝试利用指针获取值.
让我们运行memcheck来看一下Valgrind对这种情况是如何反应的.
$ valgrind --tool=memcheck ./val
==2849== Memcheck, a memory error detector
==2849== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==2849== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for right info
==2849== Command: ./val
==2849==

[a]
==2849== Invalid read of size 1
==2849== at 0x400603: main (valgrind.c:30)
==2849== Address 0x51b0040 is 0 bytes inside a block of size 1 free'd
==2849== at 0x4C270BD: free (vg_replace_malloc.c:366)
==2849== by 0x4005FE: main (valgrind.c:29)
==2849==
==2849==
==2849== HEAP SUMMARY:
==2849== in use at exit: 0 bytes in 0 blocks
==2849== total heap usage: 1 allocs, 1 frees, 1 bytes allocated
==2849==
==2849== All heap blocks were freed -- no leaks are possible
==2849==
==2849== For counts of detected and suppressed errors, rerun with: -v
==2849== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)

从上面的输出内容可以看到，Valgrind检测到了无效的读取操作然后输出了警告 ‘Invalid read of size 1′.
另注,使用gdb来调试c程序.
3. 从已分配内存块的尾部进行读/写
Code :
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
char *p = malloc(1);
*p = 'a';

char c = *(p+1);

printf("\n [%c]\n",c);

free(p);
return 0;
}

在上面的代码中，我们已经为‘p’分配了一个字节的内存,但我们在将值读取到 ‘c’中的时候使用的是地址p+1.
现在我们使用Valgrind运行上面的代码 :
$ valgrind --tool=memcheck ./val
==2835== Memcheck, a memory error detector
==2835== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==2835== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for right info
==2835== Command: ./val
==2835==
==2835== Invalid read of size 1
==2835== at 0x4005D9: main (valgrind.c:25)
==2835== Address 0x51b0041 is 0 bytes after a block of size 1 alloc'd
==2835== at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==2835== by 0x4005C5: main (valgrind.c:22)
==2835==

[]
==2835==
==2835== HEAP SUMMARY:
==2835== in use at exit: 0 bytes in 0 blocks
==2835== total heap usage: 1 allocs, 1 frees, 1 bytes allocated
==2835==
==2835== All heap blocks were freed -- no leaks are possible
==2835==
==2835== For counts of detected and suppressed errors, rerun with: -v
==2835== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)

同样，该工具在这种情况下也检测到了无效的读取操作.
4. 内存泄露
Code:
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
char *p = malloc(1);
*p = 'a';

char c = *p;

printf("\n [%c]\n",c);

return 0;
}

在这次的代码中, 我们申请了一个字节但是没有将它释放.现在让我们运行Valgrind看看会发生什么：
$ valgrind --tool=memcheck --leak-check=full ./val
==2888== Memcheck, a memory error detector
==2888== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==2888== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for right info
==2888== Command: ./val
==2888==

[a]
==2888==
==2888== HEAP SUMMARY:
==2888== in use at exit: 1 bytes in 1 blocks
==2888== total heap usage: 1 allocs, 0 frees, 1 bytes allocated
==2888==
==2888== 1 bytes in 1 blocks are definitely lost in loss record 1 of 1
==2888== at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==2888== by 0x400575: main (valgrind.c:6)
==2888==
==2888== LEAK SUMMARY:
==2888== definitely lost: 1 bytes in 1 blocks
==2888== indirectly lost: 0 bytes in 0 blocks
==2888== possibly lost: 0 bytes in 0 blocks
==2888== still reachable: 0 bytes in 0 blocks
==2888== suppressed: 0 bytes in 0 blocks
==2888==
==2888== For counts of detected and suppressed errors, rerun with: -v
==2888== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)

输出行(上面加粗的部分)显示，该工具能够检测到内存的泄露.

E. 如何阅读luajit的代码

为什么要看luajit的源码
作为目前最快的脚本语言之一，luajit确实是一个杰作，但相比原生lua仅仅几万行的代码而言，luajit却可以说是巨无霸。更要命的是，luajit之所以快，是因为大量使用了机器码相关的技术，无论是它的机器码编译部分，还是字节码执行部分，读起来都非常麻烦。
网上这方面的资料非常少，即使是lua社区的云风大大也主要以分析原生lua为主，跟luajit有很多不同。万一遇到了性能坑，或者其他难以解决的问题，需要找到原因，又不能阅读源码的话，就只能依赖网上其他人的结论，否则完全无从下手。
调试luajit
万事的开头，从能够自己调试代码开始
一个能调试的代码，阅读起来会远远比眼看要清晰得多。
而如果能利用visual studio进行调试，那么对读luajit而言还是非常有帮助的，毕竟借助visual assist的代码查找，能够非常快的帮你找到你想了解的东西
luajit下面提供了一个msvcbuild.bat用于编译luajit，但如果你需要调试的话，可以进行以下几个步骤：
1.将luajit解压，比如解压到LuaJIT-2.1.0-beta2_msvc目录
2.如果要得到精确的栈，修改LuaJIT-2.1.0-beta2_msvc\src\msvcbuild.bat，搜索/O2，将/O2改为/Od
3.在win64版本的visual studio命令行，执行一次msvcbuild.bat debug，这时会生成luajit.exe，测试一下exe是否正常。
4.用visual studio建立一个命令行工程，例如工程保存在LuaJIT-2.1.0-beta2_msvc\luajitcmd
5.把LuaJIT-2.1.0-beta2_msvc\src下所有.h和.c代码加入工程
6.把工程的调试路径设置为
命令：$(ProjectDir)..\..\src\luajit.exe
工作目录：$(ProjectDir)..\..\src\
7.此时你可以正常按f5下断点调试了
至于可以调试什么呢？
最简单就是写一个lua文件，require之，执行里面的代码，下断点观察luajit的行为。
这里必须说明，luajit的执行过程中有两大部分是没有.c对应的：
1.有一部分代码是通过dasm工具生成的，这部分直接通过汇编生成，没有.c，所以没有办法在visual studio调试（其实也可以，但是只能汇编调试）。这些主要是lua虚拟机的代码（是的，为了快，作者hand tune汇编的方式来写lua虚拟机）
2.luajit会通过jit模块编译一部分代码变为高度优化的机器码，这些也是临时生成的可执行机器码，你只能在.c看到他们是如何生成的，但执行阶段当然是没有.c对应的。
除此以外，几乎所有东西都可以直接vs调试：所有的编译过程、所有的lua标准库和api、luatable等常规数据结构、profiler，等等
下一步我们会简单说一下代码结构，以及结果luajit一些基本原理来说说怎么阅读
尤其是luajit的原理，如果对此毫无了解的情况下，阅读其源码是十分困难的，因为luajit从编译到执行的过程，走了很多步，跨越了多个模块，涉及了三种不同形式的编码（bytecode, SSA IR, 机器码），可见其复杂程度。

F. 为什么用 lua 替换 luajit

1、新建一个名为1.lua的文件，里面只有一句话print("Hello Lua")，新建一个空的out.lua脚本文件
2、开始--运行--cmd
3、luac -o out.lua 1.lua
注： luac -o [编译后脚本名] [脚本名]，必要时带上脚本路径，如：回车之后，再打开out.lua就可以看到编译好的字节码了然后实验一下，执行这个字节码脚本，可以看到lua原生的解释器可以直接解析luac编译出来的bytecode脚本，很方便！重点：
做完了以上的一系列之后，我照着这个方法编译项目中的脚本，然后在cocos2dx环境下使用，发现不行！于是又查了一下资料，发现2dx使用的是luajit，lua原生编译出来的bytecode和luajit是不兼容的，所以照着上面方法编译出来的bytecode脚本无法在2dx中使用。
解决这个问题其实很简单，就是用2dx自带的luajit编译lua脚本，下面附上luajit编译bytecode的方法：
1、在cocos2d-x-2.2.3\scripting\lua\luajit\LuaJIT-2.0.1\src目录下有个msvcbuild.bat批处理文件，需要先把luajit.exe这个东西给编译出来。
2、打开visual studio的命令行工具，这个只要装了vs都会有，在安装目录里面可以找到。
3、用vs的命令行工具cd到luajit的src目录
4、执行msvcbuild.bat批处理文件，编译出luajit.exe编译完成之后，会在src目录下生成一系列文件，其中有一个luajit.exe接下来就可以使用luajit.exe编译lua脚本的bytecode了：luajit -b [脚本名] [编译后的脚本名]，执行完后会在src目录下生成一个已经编译成bytecode的jit.lua文件
下面把编译之后的jit.lua放在2dx中试一下，以HelloLua工程为基础，把jit.lua放到\samples\Lua\HelloLua\Resources下，修改AppDelegate.cpp中的lua调用为std::string path = CCFileUtils::sharedFileUtils()->fullPathForFilename("jit.lua");