lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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
line-by-line, character-by-character?

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.