[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua library
- From: Philipp Janda <siffiejoe@...>
- Date: Wed, 17 Aug 2016 17:00:21 +0200
Am 17.08.2016 um 06:07 schröbte Peter Chen:
I am pretty new to Lua. I am trying to use it as a policy language
in ARM TrustZone. I want to compile it into my application directly
from source. I am using OPTEE-OS which has a minimal libc. I took a
look at the Makefile in the src/. It seems that there is CORE_O and
LIB_O for building liblua.
My use case is that a part of a file will be Lua script. My C
application will parse this file and feed the chunks in a buffer to
Lua interpreter through the C API.
I have the following questions:
1) Is libLua the C API I develop against (can it do everything that
is in the Programming in Lua PART IV)? If not....the only object files
it doesn't include is lua.c and luac.c...so...
Yes. `liblua.a` contains the Lua C API (amongst others). `lua.c` and
`luac.c` are essentially sample programs that use `liblua.a`.
2) I just require the interpreter and some of the standard
libraries. I do not need coroutine, package, io, module, os, utf8 or
debug std library. To remove these, which object files in LIB_O should
I leave out? I can see lcorolib.o, loadlib.o, oslib.o, but the rest is
hard to do a one-to-one match. Would this break Lua build in any way?
You also have to modify the static array in `linit.c`.
Here is the list for Lua 5.3.3:
* lbaselib.c => Lua base library
* lbitlib.c => Lua bit32 module
* lcorolib.c => Lua coroutine module
* ldblib.c => Lua debug module
* liolib.c => Lua io module
* lmathlib.c => Lua math module
* loslib.c => Lua os module
* lstrlib.c => Lua string module
* ltablib.c => Lua table module
* lutf8lib.c => Lua utf8 module
* loadlib.c => Lua package module and `require` function
You can remove individual Lua standard modules without problems (or you
can add your own). The only LIB_O files you'll probably need are
`lauxlib.o` for all `luaL_*` API functions (like `luaL_loadbufferx`) and
`linit.o` (or a replacement) which defines which standard libraries
should be loaded.
3a) I see luaL_loadbufferx() as the C API to give a buffer to Lua
interpreter. I am wondering what the semantic is. Does the buffer you
give have to be a complete Lua script? Or can you repeatedly feed it
It has to be a complete Lua chunk. If your Lua code arrives piecemeal,
you can use `lua_load()`. However, this is still pull-mode. If you want
push-mode, you'll have to do your own buffer handling (you can use the
`luaL_Buffer` API) and call `luaL_loadbuffer(x)` when your code is complete.
3b) Does it run the script automatically or is there a function I
have to call to evaluate the script in the buffer?
It compiles the given code into a function that is left at the top of
the stack. You have to call this function yourself using
`lua_(p)call(k)`, or you can do anything else you'll want to do with a
Lua function (passing it around, making a coroutine, ...).
3c) If it runs automatically, what if my script has functions
also, how do I call a specific Lua function to run in the script?
It doesn't run automatically, *you* have to run it. After you've done
that, you can access its return values, query the globals it has set,
and/or call the (global) functions your script has defined.
3d) Once I run luaL_loadbufferx(), how do I get the return value
of the Lua script?
The return values are on the Lua stack after your `lua_(p)call(k)` call.
I really only need a minimal version of the Lua. Just the
interpreter, C API, auxiilary library base, string, table, and math
standard libraries. The reason I want to remove unnecessary parts is
that I am not sure what OPTEE is missing in its libc (so far I think I
might be missing setjmp/longjmp).
This is a tough one! `setjmp` and `longjmp` are essential for error
handling and coroutine yielding. You could use C++ exceptions or some
equivalent POSIX functions instead, but you definitely need something
like this. See `ldo.c` for available options.